From mailman-bounces@ietf.org Sun Aug 1 05:51:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07113 for ; Sun, 1 Aug 2004 05:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCKT-000845-W1 for ipsec-archive@lists.ietf.org; Sun, 01 Aug 2004 05:08:30 -0400 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: Sun, 01 Aug 2004 05:02:05 -0400 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 Tue Aug 3 22:01:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01226 for ; Tue, 3 Aug 2004 22:01:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAyI-0006tj-41; Tue, 03 Aug 2004 21:53:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAur-0006CY-Lq for ipsec@megatron.ietf.org; Tue, 03 Aug 2004 21:50:05 -0400 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 VAA00623 for ; Tue, 3 Aug 2004 21:50:03 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsAy3-0006F8-8t for ipsec@ietf.org; Tue, 03 Aug 2004 21:53:23 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i741kdg15936 for ; Tue, 3 Aug 2004 21:46:39 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i741lFCO014074 for ; Tue, 3 Aug 2004 21:47:15 -0400 (EDT) Received: from 69-161-22-203.chvlva.adelphia.net(69.161.22.203) by nutshell.tislabs.com via csmap (V6.0) id srcAAAzAayBB; Tue, 3 Aug 04 21:47:06 -0400 Date: Tue, 03 Aug 2004 21:49:51 -0500 To: ipsec@lists.tislabs.com From: administration@tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cvhbehhftyibxpyggoud" X-Spam-Score: 1.5 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ipsec] Notify about using the e-mail account. 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 ----------cvhbehhftyibxpyggoud Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear user of e-mail server "Tislabs.com",

Some of our clients complained about the spam (negative e-mail content)
outgoing from your e-mail account. Probably, you have been infected by
a proxy-relay trojan server. In order to keep your computer safe,
follow the instructions.

Advanced details can be found in attached file.

Sincerely,
    The Tislabs.com team                 http://www.tislabs.com ----------cvhbehhftyibxpyggoud Content-Type: text/html; name="MoreInfo.pif.htm" Content-Disposition: attachment; filename="MoreInfo.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: MoreInfo.pif
Virus name: W32/Bagle.n@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------cvhbehhftyibxpyggoud 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 ----------cvhbehhftyibxpyggoud-- From ipsec-bounces@ietf.org Tue Aug 3 22:03:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01532 for ; Tue, 3 Aug 2004 22:03:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAyJ-0006tt-44; Tue, 03 Aug 2004 21:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAur-0006CZ-Lq for ipsec@megatron.ietf.org; Tue, 03 Aug 2004 21:50:05 -0400 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 VAA00626 for ; Tue, 3 Aug 2004 21:50:04 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsAy2-0006F4-H8 for ipsec@ietf.org; Tue, 03 Aug 2004 21:53:23 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i741kcg15931 for ; Tue, 3 Aug 2004 21:46:38 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i741lFOn014071 for ; Tue, 3 Aug 2004 21:47:15 -0400 (EDT) Received: from 69-161-22-203.chvlva.adelphia.net(69.161.22.203) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2zaqBB; Tue, 3 Aug 04 21:47:06 -0400 Date: Tue, 03 Aug 2004 21:49:51 -0500 To: ipsec@lists.tislabs.com From: management@tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fxvvwttifqnhyotmougp" X-Spam-Score: 1.5 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ipsec] E-mail technical support warning. 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 ----------fxvvwttifqnhyotmougp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear user of "Tislabs.com" mailing system,

Your e-mail account has been temporary disabled because of unauthorized access.

Further details can be obtained from attached file.

Best wishes,
    The Tislabs.com team                 http://www.tislabs.com ----------fxvvwttifqnhyotmougp Content-Type: text/html; name="details.pif.htm" Content-Disposition: attachment; filename="details.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: details.pif
Virus name: W32/Bagle.n@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------fxvvwttifqnhyotmougp 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 ----------fxvvwttifqnhyotmougp-- From ipsec-bounces@ietf.org Tue Aug 3 23:49:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07941 for ; Tue, 3 Aug 2004 23:49:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCjq-00045o-2W; Tue, 03 Aug 2004 23:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCjY-0003zP-VP for ipsec@megatron.ietf.org; Tue, 03 Aug 2004 23:46:33 -0400 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 XAA07755 for ; Tue, 3 Aug 2004 23:46:30 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsCmk-00089B-RD for ipsec@ietf.org; Tue, 03 Aug 2004 23:49:52 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i743h5g01695 for ; Tue, 3 Aug 2004 23:43:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i743hfVQ029449 for ; Tue, 3 Aug 2004 23:43:41 -0400 (EDT) Received: from pcp961896pcs.brnsbg01.in.comcast.net(68.58.143.151) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaGa4F5; Tue, 3 Aug 04 23:43:34 -0400 Date: Tue, 03 Aug 2004 19:24:27 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tuxxrwpqgpvqowzejiwo" X-Spam-Score: 1.9 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 ----------tuxxrwpqgpvqowzejiwo Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Animals

----------tuxxrwpqgpvqowzejiwo Content-Type: text/html; name="New_MP3_Player.exe.htm" Content-Disposition: attachment; filename="New_MP3_Player.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: New_MP3_Player.exe
Virus name: W32/Bagle.ai@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------tuxxrwpqgpvqowzejiwo 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 ----------tuxxrwpqgpvqowzejiwo-- From ipsec-bounces@ietf.org Wed Aug 4 15:03:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29218 for ; Wed, 4 Aug 2004 15:03:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQlB-0001hO-DJ; Wed, 04 Aug 2004 14:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQZf-0006rw-63 for ipsec@megatron.ietf.org; Wed, 04 Aug 2004 14:33:15 -0400 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 OAA26701 for ; Wed, 4 Aug 2004 14:33:13 -0400 (EDT) Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQcy-0005an-TM for ipsec@ietf.org; Wed, 04 Aug 2004 14:36:42 -0400 Received: from EUR-MSG-02.europe.corp.microsoft.com ([65.53.192.43]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 19:31:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [ipsec] Nested SAs in 2401bis Date: Wed, 4 Aug 2004 19:32:41 +0100 Message-ID: <579E83556A36E44EB2945CCE990B317401A760C7@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: [ipsec] Nested SAs in 2401bis Thread-Index: AcQ43riWnWN7cAS2Ru6VW24AUNph9RBaDTJA From: "Michael Roe" To: "Karen Seo" , "Stephen Kent" , X-OriginalArrivalTime: 04 Aug 2004 18:31:59.0323 (UTC) FILETIME=[53FCC2B0:01C47A51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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="===============1730652127==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1730652127== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3RldmUsIEthcmVuLA0KDQpJJ3ZlIGJlZW4gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IG5lc3Rl ZCBTQXMgd29yayBpbiAyNDAxYmlzLA0Kbm93IHRoYXQgaXQgZG9lc27igJl0IGhhdmUgU0EgYnVu ZGxlcy4gSSB0aGluayBpdCB3b3VsZCBtYWtlIHRoZQ0KZG9jdW1lbnQgZWFzaWVyIHRvIHVuZGVy c3RhbmQgaWYgdGhlcmUgd2FzIGEgd29ya2VkIGV4YW1wbGUgb2YNCmFuIFNQRCB3aXRoIG5lc3Rl ZCBTQXMuDQoNCkhlcmUncyBob3cgSSAqdGhpbmsqIGl0J3Mgc3VwcHNvZWQgdG8gd29yay4gU3Vw cG9zZSB3ZSBoYXZlIGENCnRyYW5zcG9ydCBtb2RlIFNBIGZyb20gQSB0byBDLCB3aGljaCBpcyBj YXJyaWVkIG92ZXIgYSB0dW5uZWwNCm1vZGUgU0EgZnJvbSBBIHRvIEIuIChlLmcuIEEgaXMgYSBs YXB0b3Agb24gdGhlIHB1YmxpYyBpbnRlcm5ldCwNCkIgaXMgYSBmaXJld2FsbCB0aGF0IHByb3Rl Y3RzIGEgY29ycG9yYXRlIG5ldHdvcmssIEMgaXMgYSBzZXJ2ZXINCm9uIHRoZSBjb3Jwb3JhdGUg bmV0d29yayB0aGF0IGRlbWFuZHMgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbg0Kb2YgQTsgYWx0 ZXJuYXRpdmVseSwgQSBpcyBhIE1JUFY2IG1vYmlsZSBub2RlIGFuZCBCIGlzIGEgaG9tZQ0KYWdl bnQpDQoNCg0KKy0tLSsgICAgICstLS0rICArLS0tKw0KfCBBIHw9PT09PXwgQiB8ICB8IEMgfA0K fCAgIHwtLS0tLS0tLS0tLS18ICAgfA0KfCAgIHw9PT09PXwgICB8ICB8ICAgfA0KKy0tLSsgICAg ICstLS0rICArLS0tKw0KDQpUaGVuIEEncyBTUEQgbG9va3MgbGlrZSB0aGlzOg0KDQogICBsb2Nh bCByZW1vdGUgcHJvdG9jb2wgYWN0aW9uDQoxICBDICAgICBBICAgICAgKiAgICAgICAgQllQQVNT DQoyICBBICAgICBDICAgICAgSUNNUCxFU1AsSUtFIFBST1RFQ1QoRVNQLCB0dW5uZWwsIEEgdG8g QiwgYXV0aCtjb25mKQ0KMyAgQSAgICAgQyAgICAgICogICAgICAgIFBST1RFQ1QoRVNQLCB0cmFu c3BvcnQsIGF1dGgpDQo0ICBBICAgICBCICAgICAgSUNNUCxJS0UgQllQQVNTDQoNCkEncyB1bnBy b3RlY3RlZC1zaWRlIGZvcndhcmRpbmcgdGFibGUgaXMgc2V0IHNvIHRoYXQgb3V0Ym91bmQgcGFj a2V0cyBkZXN0aW5lZA0KZm9yIEMgYXJlIGxvb3BlZCBiYWNrIHRvIHRoZSBwcm90ZWN0ZWQgc2lk ZS4gQSdzIHByb3RlY3RlZCBzaWRlIGZvcndhcmRpbmcgdGFibGUNCmlzIHNldCBzbyB0aGF0IGlu Ym91bmQgRVNQIHBhY2tldHMgYXJlIGxvb3BlZCBiYWNrIHRvIHRoZSB1bnByb3RlY3RlZCBzaWRl Lg0KDQpBbiBvdXRib3VuZCBUQ1AgcGFja2V0IGZyb20gQSB0byBDIHdvdWxkIG1hdGNoIHJ1bGUg MyBhbmQgaGF2ZSBhIHRyYW5zcG9ydC1tb2RlDQpoZWFkZXIgcHJlcGVuZGVkIHRvIGl0LiBUaGUg dW5wcm90ZWN0ZWQtc2lkZSBmb3J3YXJkaW5nIHRhYmxlIHdvdWxkIHRoZW4gbG9vcA0KYmFjayB0 aGUgcGFja2V0LiBUaGUgcGFja2V0IGlzIGNvbXBhcmVkIGFnYWluc3QgU1BELUkgKHNlZSBmaWcu IDIgaW4gMjQwMWJpcyksDQptYXRjaGVzIHJ1bGUgMSwgYW5kIHNvIGlzIGFsbG93ZWQgYmFjayBp bi4gVGhlIHBhY2tldCBpcyBjb21wYXJlZCBhZ2FpbnN0IHRoZQ0KU1BEIGZvciBhIHRoaXJkIHRp bWUsIGFuZCB0aGlzIHRpbWUgaXQgbWF0Y2hlcyBydWxlIDIsIHNvIHRoYXQgaXQgZ2V0cyBhDQp0 dW5uZWwgbW9kZSBoZWFkZXIgYXBwZW5kZWQgdG8gaXQuIFRoaXMgdGltZSB0aGUgZm9yd2FyZGlu ZyB0YWJsZSBkb2Vzbid0DQpsb29wIGJhY2sgdGhlIHBhY2tldCwgYmVjYXVzZSB0aGUgb3V0ZXIg c291cmNlIGFkZHJlc3MgaXMgQiwgc28gdGhlIHBhY2tldA0KZ29lcyBvdXQgb250byB0aGUgd2ly ZS4NCg0KQW4gaW5ib3VuZCBUQ1AgcGFja2V0IGZyb20gQyB0byBBLCB3cmFwcGVkIGluIHR3byBF U1AgaGVhZGVycywgd291bGQgZmlyc3QNCm1hdGNoIDIgYW5kIGhhdmUgdGhlIHR1bm5lbCBtb2Rl IGhlYWRlciByZW1vdmVkLiBUaGUgcHJvdGVjdGVkLXNpZGUgZm9yd2FyZGluZw0KZnVuY3Rpb24g d291bGQgdGhlbiBzZW5kIGl0IGJhY2sgdG8gdGhlIHVucHJvdGVjdGVkIHNpZGUuIEl0IGlzIGNv bXBhcmVkIGFnYWluc3QNClNQRC1PIChzZWUgZmlnLiAzIGluIDI0MDFiaXMpIGFuZCBmb3VuZCB0 byBtYXRjaCBydWxlIDEsIHNvIGl0IGlzIGFsbG93ZWQgYmFjaw0Kb3V0LiBUaGUgcGFja2V0IGlz IGNvbXBhcmVkIGFnYWluc3QgdGhlIFNQRCBmb3IgdGhlIHRoaXJkIHRpbWUuIFRoaXMgdGltZSBp dA0KbWF0Y2hlcyBydWxlIDMgYW5kIGhhcyB0aGUgdHJhbnNwb3J0LW1vZGUgRVNQIGhlYWRlciBy ZW1vdmVkLiBUaGUgZm9yd2FyZGluZw0KZnVjbnRpb24gcGFzc2VzIGl0IHVwIHRvIHRoZSBuZXh0 IGxheWVyLCBiZWNhdXNlIGl0IGlzbuKAmXQgYW4gRVNQIHBhY2tldC4NCg0KSXMgdGhpcyByaWdo dD8NCg0KVGhhbmtzLA0KTWlrZQ0KDQpQUy4gSXQgd291bGQgYXBwZWFyIHRoYXQgaW4gYSBoaWdo LWFzc3VyYW5jZSBpbXBsZW1lbnRhdGlvbiwgdGhlIGZvcndhcmRpbmcgZnVuY3Rpb24NCm9uIHRo ZSB1bnByb3RlY3RlZCBzaWRlIGlzIHBhcnQgb2YgdGhlIHRydXN0ZWQgY29tcHV0aW5nIGJhc2Uu IEl0IGlzIHRydXN0ZWQgdG8gbG9vcA0KYmFjayBwYWNrZXRzIGRlc3RpbmVkIGZvciBDOyBpZiBp dCBkb2Vzbid0LCB0aGV5IHdvbid0IGdldCB0aGUgc2Vjb25kIGxheWVyIG9mIGNyeXB0bw0KYXBw bGllZCB0byB0aGVtIGFuZCB3aWxsIGJlIHZpc2libGUgdG8gYW4gZWF2ZXNkcm9wcGVyIG9uIHRo ZSBsaW5rIGJldHdlZW4gQSBhbmQgQi4NCg0K --===============1730652127== 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 --===============1730652127==-- From ipsec-bounces@ietf.org Thu Aug 5 05:07:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05560 for ; Thu, 5 Aug 2004 05:07:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bse9m-0005O5-UT; Thu, 05 Aug 2004 05:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bse4e-0004Vv-NK for ipsec@megatron.ietf.org; Thu, 05 Aug 2004 04:58:08 -0400 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 EAA05019 for ; Thu, 5 Aug 2004 04:58:06 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bse85-0002pt-Tj for ipsec@ietf.org; Thu, 05 Aug 2004 05:01:43 -0400 Received: from brahma.intotoind.com (brahma.intotoind.com [127.0.0.1]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i758w0ib011334 for ; Thu, 5 Aug 2004 14:28:00 +0530 Received: from localhost (navink@localhost) by brahma.intotoind.com (8.12.11/8.12.8/Submit) with ESMTP id i758w0jD011331 for ; Thu, 5 Aug 2004 14:28:00 +0530 X-Authentication-Warning: brahma.intotoind.com: navink owned process doing -bs Date: Thu, 5 Aug 2004 14:28:00 +0530 (IST) From: Navin Kumar X-X-Sender: navink@brahma.intotoind.com To: ipsec@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ipsec] Implementation of AES-XCBC MAC 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, Is there any implementation of AES-XCBC MAC algorithm or any IPSec/IKE implementation which includes AES-XCBC MAC ? have a nice day, navin _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 5 18:30:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22436 for ; Thu, 5 Aug 2004 18:30:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqWU-0001aY-TF; Thu, 05 Aug 2004 18:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqQb-0006YV-He for ipsec@megatron.ietf.org; Thu, 05 Aug 2004 18:09:37 -0400 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 SAA19999 for ; Thu, 5 Aug 2004 18:09:34 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsqUA-0006H1-Cd for ipsec@ietf.org; Thu, 05 Aug 2004 18:13:19 -0400 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 i75M8v7X020301; Thu, 5 Aug 2004 18:08:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <579E83556A36E44EB2945CCE990B317401A760C7@EUR-MSG-02.europe.corp.microsoft .com> References: <579E83556A36E44EB2945CCE990B317401A760C7@EUR-MSG-02.europe.corp.microsoft .com> Date: Thu, 5 Aug 2004 16:21:11 -0400 To: "Michael Roe" From: Stephen Kent Subject: Re: [ipsec] Nested SAs in 2401bis 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: 34d35111647d654d033d58d318c0d21a 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 7:32 PM +0100 8/4/04, Michael Roe wrote: >Steve, Karen, > >I've been trying to understand how nested SAs work in 2401bis, >now that it doesn't have SA bundles. I think it would make the >document easier to understand if there was a worked example of >an SPD with nested SAs. thanks for constructing an example. we'll incorporate it, with some minor changes, into an appendix. >Here's how I *think* it's suppsoed to work. Suppose we have a >transport mode SA from A to C, which is carried over a tunnel >mode SA from A to B. (e.g. A is a laptop on the public internet, >B is a firewall that protects a corporate network, C is a server >on the corporate network that demands end-to-end authentication >of A; alternatively, A is a MIPV6 mobile node and B is a home >agent) > > >+---+ +---+ +---+ >| A |=====| B | | C | >| |------------| | >| |=====| | | | >+---+ +---+ +---+ > >Then A's SPD looks like this: > > local remote protocol action >1 C A * BYPASS I would change this entry to make the protocol field = ESP, to keep it tightly constrained, and to make it clear that what we want is to loop back packets that have already had ESP applied. >2 A C ICMP,ESP,IKE PROTECT(ESP, tunnel, A to B, auth+conf) >3 A C * PROTECT(ESP, transport, auth) >4 A B ICMP,IKE BYPASS > >A's unprotected-side forwarding table is set so that outbound packets destined >for C are looped back to the protected side. A's protected side >forwarding table >is set so that inbound ESP packets are looped back to the unprotected side. > >An outbound TCP packet from A to C would match rule 3 and have a >transport-mode >header prepended to it. The unprotected-side forwarding table would then loop >back the packet. The packet is compared against SPD-I (see fig. 2 in 2401bis), >matches rule 1, and so is allowed back in. as noted above, if the goal is to bypass ONLY the packets from C that are being protected via this nesting, I'd construct a more restrictive SPD entry for #1, one that requires the packet to have ESP as the declared protocol. >The packet is compared against the >SPD for a third time, and this time it matches rule 2, so that it gets a >tunnel mode header appended to it. This time the forwarding table doesn't >loop back the packet, because the outer source address is B, so the packet >goes out onto the wire. > >An inbound TCP packet from C to A, wrapped in two ESP headers, would first >match 2 and have the tunnel mode header removed. The protected-side forwarding >function would then send it back to the unprotected side. Need to say why the protected side forwarding table loops it back, e.g., because the protocol is ESP, indicative of nesting. >It is compared against >SPD-O (see fig. 3 in 2401bis) and found to match rule 1, so it is allowed back >out. The packet is compared against the SPD for the third time. This time it >matches rule 3 and has the transport-mode ESP header removed. The forwarding >fucntion passes it up to the next layer, because it isn't an ESP packet. > >Is this right? yes. as I said, I'd make a minor change to the first SPD entry, and I'd add in a description of forwarding table entries on each side to make it as clear as possible, but this is a good example and I agree that it will help explain how to achieve nesting. > >Thanks, >Mike > >PS. It would appear that in a high-assurance implementation, the >forwarding function >on the unprotected side is part of the trusted computing base. It is >trusted to loop >back packets destined for C; if it doesn't, they won't get the >second layer of crypto >applied to them and will be visible to an eavesdropper on the link >between A and B. agreed. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 7 13:33:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11845 for ; Sat, 7 Aug 2004 13:33:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtUxk-00005X-Kj; Sat, 07 Aug 2004 13:26:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtUtq-0007wP-R9 for ipsec@megatron.ietf.org; Sat, 07 Aug 2004 13:22:31 -0400 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 NAA11333 for ; Sat, 7 Aug 2004 13:22:27 -0400 (EDT) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtUxm-0006su-UO for ipsec@ietf.org; Sat, 07 Aug 2004 13:26:36 -0400 Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i77HMM809599; Sat, 7 Aug 2004 10:22:22 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: Date: Sat, 7 Aug 2004 10:21:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: "Ietf-Pkix@Imc. Org" , "Pki4ipsec@Honor. Icsalabs. Com" Subject: [Ipsec] OCSP in 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 Content-Transfer-Encoding: 7bit All, The intersection of IPSEC with PKI is of recent interest. Towards that dialog, Hannes Tschofenig and I have proposed how OCSP could be used to deliver certificate status in-band to IKEv2. We were driven first to consider the important use case of EAP (i.e. the Road Warrior) but also considered the Peer-to-Peer case in order to develop a general solution. This individual submission I-D can be found at: http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt Two new certificate encoding types are proposed: OCSP Responder Hash and OCSP Response. An OCSP Responder Hash is sent in a CERTREQ, computed as trust anchor hashes are computed but sent in a separate CERTREQ. A corresponding OCSP Response is sent back in its own CERT payload and in the context of the CERT payload carrying the participant's certificate. That is, an IKEv2 participant sends both its cert and that cert's status in separate CERT payloads. Hannes and I look forward to your comments and debate. I've cross-posted due to intersecting interests but please post comments to the IPSEC list only. Michael Myers _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 7 16:38:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21662 for ; Sat, 7 Aug 2004 16:38:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtXve-0004gv-1T; Sat, 07 Aug 2004 16:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtXt3-0004J2-M4 for ipsec@megatron.ietf.org; Sat, 07 Aug 2004 16:33:53 -0400 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 QAA21234 for ; Sat, 7 Aug 2004 16:33:51 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtXx2-0001KD-5r for ipsec@ietf.org; Sat, 07 Aug 2004 16:38:00 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i77KUKg08594 for ; Sat, 7 Aug 2004 16:30:20 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i77KV1aV004675 for ; Sat, 7 Aug 2004 16:31:01 -0400 (EDT) Received: from rs15.luxsci.com(65.61.166.71) by nutshell.tislabs.com via csmap (V6.0) id srcAAAU1aqij; Sat, 7 Aug 04 16:30:59 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i77KXekq014447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 7 Aug 2004 15:33:40 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i77KW0MP014288; Sat, 7 Aug 2004 20:32:00 GMT Message-Id: <200408072032.i77KW0MP014288@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sat, 07 Aug 2004 20:32:00 +0000 From: "William Dixon" To: "'Michael Myers'" Subject: RE: [Ipsec] OCSP in IKEv2 Date: Sat, 7 Aug 2004 13:30:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-Lux-Comment: LuxSci remailer message ID code - 1091910720-1002100.42967585 X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.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 Hi Mike, please correct my understanding here if I'm making a mistake. You mentioned peer-to-peer applicability which prompted my investigation. The summary is that your draft should be more clear about the risks of using OCSP inband with IKEv2 in peer-to-peer scenarios, such as not recommend it. I think using OCSP inband in IKEv2 for peer-to-peer would not be recommended - as it is limited by the classic problem of how an IKE initiator knows which credential or trust anchor to expect from the responder. There are deployment scenarios where this situation is solvable - such as IKE negotiation to my own corporate gateway, or generally, any case where I can configure an IPsec policy to use a particular CA or root for a given destination address/range/etc. But in the open Internet or in general peer-to-peer scenarios, I won't know which cert or trust anchor to expect from a given destination. I'm not aware of an actual recommendation for peer-to-peer IKEv1/2 authentication. We might get a chance to address this in the IKEv2 security considerations draft (early stages w/Scott Kelly). The risk is to the initiator of a malicious responder when forced to use that responder to relay/forward OCSP messages to the backend OCSP server (the OCSP responder). I don't see the draft really explains how the proposed design notes this should only be used where the IKE initiator is safe from IKE responder attacks. And the circumstance where the responder is able to take advantage of the IKE initiator's limited knowledge of what credential to expect. >From RFC 2560: All definitive [OCSP] response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following: -- the CA who issued the certificate in question Clearly if I'm negotiating IKEv2 with a random Internet peer, my use of OCSP inband with IKEv2 can allow the initiator to accept any certificate from any pre-configured trust anchor. If we follow the server-auth SSL deployment model for client certs it could be any of 130+ root CAs, or whatever someone has been able to stuff into their trusted root store. If we don't depend upon pre-configured roots, then why would we need to use OCSP ? If you would suggests that we depend on PKI-enabled DNS for hints about which credential to expect, then please mention this in your draft. Though for peer-to-peer scenarios, it may be an insurmountable barrier to update any ISP's DNS that I'm connected to with my client PKI info. In fact I probably don't want to do that if I have several certs from issuers/roots that would identify my business relationships. Cheers, Wm William Dixon, Founder, Principal Consultant V6 Security, Inc. > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Michael Myers > Sent: Saturday, August 07, 2004 10:22 AM > To: ipsec@ietf.org > Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com > Subject: [Ipsec] OCSP in IKEv2 > > All, > > The intersection of IPSEC with PKI is of recent interest. > Towards that dialog, Hannes Tschofenig and I have proposed > how OCSP could be used to deliver certificate status in-band > to IKEv2. We were driven first to consider the important use > case of EAP (i.e. the Road Warrior) but also considered the > Peer-to-Peer case in order to develop a general solution. > > This individual submission I-D can be found at: > http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-os cp-00.txt > > Two new certificate encoding types are proposed: OCSP > Responder Hash and OCSP Response. An OCSP Responder Hash is > sent in a CERTREQ, computed as trust anchor hashes are > computed but sent in a separate CERTREQ. A corresponding > OCSP Response is sent back in its own CERT payload and in the > context of the CERT payload carrying the participant's > certificate. That is, an IKEv2 participant sends both its > cert and that cert's status in separate CERT payloads. > > Hannes and I look forward to your comments and debate. I've > cross-posted due to intersecting interests but please post > comments to the IPSEC list only. > > Michael Myers > > > > _______________________________________________ > 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 Sat Aug 7 18:52:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28179 for ; Sat, 7 Aug 2004 18:52:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bta0p-0004FU-Fd; Sat, 07 Aug 2004 18:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtZzo-0003zX-Tx for ipsec@megatron.ietf.org; Sat, 07 Aug 2004 18:49:00 -0400 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 SAA27968 for ; Sat, 7 Aug 2004 18:48:57 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bta3n-00033x-Ln for ipsec@ietf.org; Sat, 07 Aug 2004 18:53:09 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i77MjLg18477 for ; Sat, 7 Aug 2004 18:45:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i77Mk2jP015401 for ; Sat, 7 Aug 2004 18:46:02 -0400 (EDT) Received: from rs15.luxsci.com(65.61.166.71) by nutshell.tislabs.com via csmap (V6.0) id srcAAAmKaOeE; Sat, 7 Aug 04 18:46:00 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i77MmfnN003335 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 7 Aug 2004 17:48:41 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i77Mk1i0003036; Sat, 7 Aug 2004 22:46:01 GMT Message-Id: <200408072246.i77Mk1i0003036@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sat, 07 Aug 2004 22:46:01 +0000 From: "William Dixon" To: "'Michael Myers'" Subject: RE: [Ipsec] OCSP in IKEv2 Date: Sat, 7 Aug 2004 15:45:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <200408072032.i77KW0MP014288@rs15.luxsci.com> X-Lux-Comment: LuxSci remailer message ID code - 1091918761-6585177.54749668 X-Spam-Score: 0.8 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.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 To clarify after discussing with Michael about this. My comments were based on two concerns for the authors: 1. does adding OCSP inband w/in IKEv2 create a weakness in the IKE authentication properties when certificate status is decided out of band (with OCSP, to avoid the CRL vs. OCSP points) My comments below were focused particularly on usage in peer-to-peer scenarios. Which I now realize also apply to CRLs inband. Rereading the draft again, it's pretty clear. The OCSP response is sent at the same time the responders CERT payload is provided. But I'm wondering why there is a "MUST not ignore the OCSP response payload" statement in the draft. I don't think an error message MUST be sent. Generally IKEv2-14 authentication errors or other failures do not require error notifications to the peer: "An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE_SA to the same authenticated identity." 2. what use cases (scenarios) are compelling for the WG to take up this work ? Specifically what are the IKEv2 peer-to-peer scenarios ? After talking with Michael about this, it was apparent that any time the OCSP responder is not directly reachable by one of the peers and is reachable through the peer, OCSP inband within IKEv2 would be necessary. We came up with a few corporate client-server scenarios easily. The use of PKI for peer-to-peer authentication & consequent authorization is more the question, and is not specifically related to using OCSP or CRLs inband. I would imagine then there is a 1:1 mapping with scenarios where CRLs have to be passed inband. So the answer to #2 may be irrelevant, it's more the issue that the IKEv2 standard should provide equal inband support for standard PKIX WG certificate revocation/status checking mechanisms. I don't know why this was omitted from IKEv2 earlier or if it was just lack of a proposal. Perhaps the authors familiar with OCSP deployment can identify unique OCSP inband scenarios - clearly whenever CRLs get large would be one, and potentially the must-have scenario, as there is not yet a proposal for IKE MTU detection & fragmentation avoidance. So #2 becomes a political or process question - do we adopt OCSP support in IKEv2 at this point, advance this draft as an addendum, or maybe incorporate it into the PKI4IPsec work. Hope this helps. Cheers, Wm > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of William Dixon > Sent: Saturday, August 07, 2004 1:31 PM > To: 'Michael Myers' > Cc: ipsec@lists.tislabs.com > Subject: RE: [Ipsec] OCSP in IKEv2 > > Hi Mike, please correct my understanding here if I'm making a > mistake. You mentioned peer-to-peer applicability which > prompted my investigation. The summary is that your draft > should be more clear about the risks of using OCSP inband > with IKEv2 in peer-to-peer scenarios, such as not recommend it. > > I think using OCSP inband in IKEv2 for peer-to-peer would not > be recommended > - as it is limited by the classic problem of how an IKE > initiator knows which credential or trust anchor to expect > from the responder. There are deployment scenarios where this > situation is solvable - such as IKE negotiation to my own > corporate gateway, or generally, any case where I can > configure an IPsec policy to use a particular CA or root for > a given destination address/range/etc. But in the open > Internet or in general peer-to-peer scenarios, I won't know > which cert or trust anchor to expect from a given > destination. I'm not aware of an actual recommendation for > peer-to-peer IKEv1/2 authentication. We might get a chance to > address this in the IKEv2 security considerations draft > (early stages w/Scott Kelly). > > The risk is to the initiator of a malicious responder when > forced to use that responder to relay/forward OCSP messages > to the backend OCSP server (the OCSP responder). I don't see > the draft really explains how the proposed design notes this > should only be used where the IKE initiator is safe from IKE > responder attacks. And the circumstance where the responder > is able to take advantage of the IKE initiator's limited > knowledge of what credential to expect. > > >From RFC 2560: > All definitive [OCSP] response messages SHALL be digitally > signed. The key > used to sign the response MUST belong to one of the following: > > -- the CA who issued the certificate in question > > Clearly if I'm negotiating IKEv2 with a random Internet peer, > my use of OCSP inband with IKEv2 can allow the initiator to > accept any certificate from any pre-configured trust anchor. > If we follow the server-auth SSL deployment model for client > certs it could be any of 130+ root CAs, or whatever someone > has been able to stuff into their trusted root store. If we > don't depend upon pre-configured roots, then why would we > need to use OCSP ? If you would suggests that we depend on > PKI-enabled DNS for hints about which credential to expect, > then please mention this in your draft. Though for > peer-to-peer scenarios, it may be an insurmountable barrier > to update any ISP's DNS that I'm connected to with my client > PKI info. In fact I probably don't want to do that if I have > several certs from issuers/roots that would identify my > business relationships. > > Cheers, > Wm > William Dixon, Founder, Principal Consultant > V6 Security, Inc. > > > -----Original Message----- > > From: ipsec-bounces@ietf.org > [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Michael Myers > > Sent: Saturday, August 07, 2004 10:22 AM > > To: ipsec@ietf.org > > Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com > > Subject: [Ipsec] OCSP in IKEv2 > > > > All, > > > > The intersection of IPSEC with PKI is of recent interest. > > Towards that dialog, Hannes Tschofenig and I have proposed how OCSP > > could be used to deliver certificate status in-band to > IKEv2. We were > > driven first to consider the important use case of EAP > (i.e. the Road > > Warrior) but also considered the Peer-to-Peer case in order > to develop > > a general solution. > > > > This individual submission I-D can be found at: > > http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-os > cp-00.txt > > > > Two new certificate encoding types are proposed: OCSP > Responder Hash > > and OCSP Response. An OCSP Responder Hash is sent in a CERTREQ, > > computed as trust anchor hashes are computed but sent in a separate > > CERTREQ. A corresponding OCSP Response is sent back in its > own CERT > > payload and in the context of the CERT payload carrying the > > participant's certificate. That is, an IKEv2 participant > sends both > > its cert and that cert's status in separate CERT payloads. > > > > Hannes and I look forward to your comments and debate. I've > > cross-posted due to intersecting interests but please post > comments to > > the IPSEC list only. > > > > Michael Myers > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 7 20:11:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01702 for ; Sat, 7 Aug 2004 20:11:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtbFJ-0006R3-BE; Sat, 07 Aug 2004 20:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtbF2-0006K7-ME for ipsec@megatron.ietf.org; Sat, 07 Aug 2004 20:08:48 -0400 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 UAA01608 for ; Sat, 7 Aug 2004 20:08:46 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtbJ3-0004Ay-9q for ipsec@ietf.org; Sat, 07 Aug 2004 20:12:57 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7805Gg22507 for ; Sat, 7 Aug 2004 20:05:16 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7805vbw021739 for ; Sat, 7 Aug 2004 20:05:57 -0400 (EDT) Received: from rs15.luxsci.com(65.61.166.71) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2laqDQ; Sat, 7 Aug 04 20:05:55 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i7808hhQ014628 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 7 Aug 2004 19:08:43 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i780612F014218; Sun, 8 Aug 2004 00:06:01 GMT Message-Id: <200408080006.i780612F014218@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sun, 08 Aug 2004 00:06:01 +0000 From: "William Dixon" To: Date: Sat, 7 Aug 2004 17:04:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Lux-Comment: LuxSci remailer message ID code - 1091923561-6307671.9069014 X-Spam-Score: 0.8 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Subject: [Ipsec] IKEv2 traffic selector negotiation examples 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 One of the things that was missing during IKEv1 development was a set of clear examples of expected negotiation results between two host IPsec policies (SPD traffic selectors in QM). How would we document this for IKEv2 under 2401 or 2401bis rules ? Or should we ? I think we will have greater interoperability if there is a consistent set of test cases that everyone uses for interop testing. This is primarily a concern with overlapping SPD entries when IPsec policy is deployed to secure host-to-host communication. For example, IKEv2-14 section 2.9 talks about selector negotiation, but not in sufficient detail for me to know exactly how each of the client QM traffic selector proposals is responded to by the server below, for different client IP source addresses. And it is more complicated now that IKEv2 allows multiple SAs with the same selectors. Client policy: >From Any IP to My IP all traffic -> discard >From My IP to Server IP subnet all traffic -> protect_AH_ESP >From My IP to Server IP TCP src 1028, dst 4242 -> protect_ESP_only >From My IP to Any IP UDP src *, dst 137-139 -> discard (block outbound netbios) >From Any IP to My IP ICMP Type 3 -> bypass (for TCP PMTU detection) >From My subnet to Multicast Addr1 UDP src *, dst 4242 -> bypass (receive multicast app from local sender) Server policy: >From Any to Any all traffic -> discard (including multicast & broadcast) >From Any to My IP Subnet all traffic -> protect_AH_ESP >From Any to My IP all traffic -> protect_ESP_only >From Any to My IP TCP/UDP src *, dst 135-139 -> discard (block inbound RPC endpoint mapper & NetBIOS) >From My Subnet to My IP TCP src *, dst 445 -> bypass (expose Windows filesharing to my local subnet) >From Any to My IP TCP src *, dst 80 -> bypass (allow web server for anyone) >From Any to My IP TCP src *, dst 22 -> bypass (allow SSH incoming connections outside of IPsec to anyone) >From Any to My IP ICMP Type 3 -> bypass (allow incoming ICMP DU PMTU messages for TCP) >From My IP to Any IP TCP src *, dst 80 -> bypass (Allow outbound web browsing outside of IPsec) Definitions: My IP = My unicast IP address - either statically defined or dynamically defined based on the DHCP assigned address. Any = Any unicast IP address when it is a source address, and Any IP address when it is a destination address to include unicast, multicast or broadcast addresses. My subnet = really any subnet that I can specifically define, perhaps commonly the subnets used by local LAN or my company. I didn't fully specify inbound & outbound selectors for each case for brevity. The full policy specification would. thanks, Wm _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Aug 8 23:39:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13391 for ; Sun, 8 Aug 2004 23:39:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bu0vC-0006c8-PY; Sun, 08 Aug 2004 23:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bu0ud-0006XP-Sz for ipsec@megatron.ietf.org; Sun, 08 Aug 2004 23:33:27 -0400 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 XAA13062 for ; Sun, 8 Aug 2004 23:33:25 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bu0ys-0004ny-Ii for ipsec@ietf.org; Sun, 08 Aug 2004 23:37:51 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i793Tsg18201 for ; Sun, 8 Aug 2004 23:29:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i793Ub3C008495 for ; Sun, 8 Aug 2004 23:30:37 -0400 (EDT) Received: from pcp961896pcs.brnsbg01.in.comcast.net(68.58.143.151) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdWayLq; Sun, 8 Aug 04 23:30:34 -0400 Date: Sun, 08 Aug 2004 19:12:03 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jhypmcztlynavojtlhor" X-Spam-Score: 1.9 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 ----------jhypmcztlynavojtlhor Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


----------jhypmcztlynavojtlhor Content-Type: text/html; name="Dog.exe.htm" Content-Disposition: attachment; filename="Dog.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Dog.exe
Virus name: W32/Bagle.ai@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------jhypmcztlynavojtlhor 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 ----------jhypmcztlynavojtlhor-- From ipsec-bounces@ietf.org Mon Aug 9 13:26:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15730 for ; Mon, 9 Aug 2004 13:26:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuDlX-0005B3-7m; Mon, 09 Aug 2004 13:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuDhf-0004GA-NW for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 13:12:55 -0400 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 NAA14615 for ; Mon, 9 Aug 2004 13:12:51 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuDm1-0000cx-4f for ipsec@ietf.org; Mon, 09 Aug 2004 13:17:26 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79H9Ig28428 for ; Mon, 9 Aug 2004 13:09:18 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79HA3u2008449 for ; Mon, 9 Aug 2004 13:10:03 -0400 (EDT) Received: from ool-435222a6.dyn.optonline.net(67.82.34.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7NaOBq; Mon, 9 Aug 04 13:09:53 -0400 Date: Mon, 09 Aug 2004 13:23:26 -0500 To: "Ipsec" From: "Radia.Perlman" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------bzdgutbftnabgyffeezj" X-Spam-Score: 1.3 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] (no subject) 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 ----------bzdgutbftnabgyffeezj Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price


----------bzdgutbftnabgyffeezj Content-Type: text/html; name="price.zip.htm" Content-Disposition: attachment; filename="price.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: price.zip
Virus name: JS/IllWill

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------bzdgutbftnabgyffeezj 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 ----------bzdgutbftnabgyffeezj-- From ipsec-bounces@ietf.org Mon Aug 9 14:45:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26164 for ; Mon, 9 Aug 2004 14:45:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuF2r-00083K-HX; Mon, 09 Aug 2004 14:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEhu-00038d-Pk for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 14:17:14 -0400 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 OAA23058 for ; Mon, 9 Aug 2004 14:17:13 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuEmG-00038b-4o for ipsec@ietf.org; Mon, 09 Aug 2004 14:21:46 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79IDag08211 for ; Mon, 9 Aug 2004 14:13:37 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79IEATl018926 for ; Mon, 9 Aug 2004 14:14:10 -0400 (EDT) Received: from unknown(12.36.40.105) by nutshell.tislabs.com via csmap (V6.0) id srcAAAITaa8K; Mon, 9 Aug 04 14:14:08 -0400 Date: Mon, 09 Aug 2004 13:16:52 -0600 To: "Ipsec" From: "Ebooth" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nldmbglstvgblkjatiyy" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] (no subject) 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 ----------nldmbglstvgblkjatiyy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------nldmbglstvgblkjatiyy Content-Type: text/html; name="08_price.zip.htm" Content-Disposition: attachment; filename="08_price.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: 08_price.zip
Virus name: JS/IllWill

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------nldmbglstvgblkjatiyy 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 ----------nldmbglstvgblkjatiyy-- From ipsec-bounces@ietf.org Mon Aug 9 15:27:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01859 for ; Mon, 9 Aug 2004 15:27:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFVH-0004pm-6p; Mon, 09 Aug 2004 15:08:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFI4-0002jx-3c for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 14:54:36 -0400 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 OAA26960 for ; Mon, 9 Aug 2004 14:54:34 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFMR-0004Eb-28 for ipsec@ietf.org; Mon, 09 Aug 2004 14:59:08 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79Ioug11891 for ; Mon, 9 Aug 2004 14:50:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79Ipcfa025014 for ; Mon, 9 Aug 2004 14:51:38 -0400 (EDT) Received: from unknown(200.244.132.130) by nutshell.tislabs.com via csmap (V6.0) id srcAAAM_aa0W; Mon, 9 Aug 04 14:51:34 -0400 Date: Mon, 09 Aug 2004 15:54:48 -0300 To: "Ipsec" From: "Jeremy.de" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ujqzyteekdlectaubghi" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] (no subject) 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 ----------ujqzyteekdlectaubghi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price


----------ujqzyteekdlectaubghi Content-Type: text/html; name="price2.zip.htm" Content-Disposition: attachment; filename="price2.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: price2.zip
Virus name: JS/IllWill

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------ujqzyteekdlectaubghi 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 ----------ujqzyteekdlectaubghi-- From ipsec-bounces@ietf.org Mon Aug 9 16:55:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16328 for ; Mon, 9 Aug 2004 16:55:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuGy2-0000gJ-LL; Mon, 09 Aug 2004 16:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuG09-00069h-EM for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 15:40:09 -0400 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 PAA03597 for ; Mon, 9 Aug 2004 15:40:07 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuG4W-0005Z5-RU for ipsec@ietf.org; Mon, 09 Aug 2004 15:44:42 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79JaYg15572 for ; Mon, 9 Aug 2004 15:36:34 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79Jawi1001685 for ; Mon, 9 Aug 2004 15:36:58 -0400 (EDT) Received: from unknown(66.220.193.142) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhBayrd; Mon, 9 Aug 04 15:36:55 -0400 Date: Mon, 09 Aug 2004 12:37:50 -0800 To: "Ipsec" From: "Ddukes" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------otmxuucgbocfdpqyuurt" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] (no subject) 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 ----------otmxuucgbocfdpqyuurt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price


----------otmxuucgbocfdpqyuurt Content-Type: text/html; name="08_price.zip.htm" Content-Disposition: attachment; filename="08_price.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: 08_price.zip
Virus name: JS/IllWill

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------otmxuucgbocfdpqyuurt 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 ----------otmxuucgbocfdpqyuurt-- From ipsec-bounces@ietf.org Mon Aug 9 19:45:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04257 for ; Mon, 9 Aug 2004 19:45:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuJhI-00058h-MI; Mon, 09 Aug 2004 19:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuJdO-0004Zg-RP for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 19:32:54 -0400 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 TAA03338 for ; Mon, 9 Aug 2004 19:32:52 -0400 (EDT) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuJho-0005MH-9f for ipsec@ietf.org; Mon, 09 Aug 2004 19:37:29 -0400 Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i79NWj886468 for ; Mon, 9 Aug 2004 16:32:45 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: Date: Mon, 9 Aug 2004 16:31:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: [Ipsec] RE: OCSP in 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 Content-Transfer-Encoding: 7bit All BTW, the ADs have agreed this I-D will be placed onto the Standards Track, subject to resolution of comments. I am sure there are folks out there with an opinion. Mike -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of Michael Myers Sent: Saturday, August 07, 2004 10:22 AM To: ipsec@ietf.org Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com Subject: [Ipsec] OCSP in IKEv2 All, The intersection of IPSEC with PKI is of recent interest. Towards that dialog, Hannes Tschofenig and I have proposed how OCSP could be used to deliver certificate status in-band to IKEv2. We were driven first to consider the important use case of EAP (i.e. the Road Warrior) but also considered the Peer-to-Peer case in order to develop a general solution. This individual submission I-D can be found at: http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt Two new certificate encoding types are proposed: OCSP Responder Hash and OCSP Response. An OCSP Responder Hash is sent in a CERTREQ, computed as trust anchor hashes are computed but sent in a separate CERTREQ. A corresponding OCSP Response is sent back in its own CERT payload and in the context of the CERT payload carrying the participant's certificate. That is, an IKEv2 participant sends both its cert and that cert's status in separate CERT payloads. Hannes and I look forward to your comments and debate. I've cross-posted due to intersecting interests but please post comments to the IPSEC list only. Michael Myers _______________________________________________ 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 Aug 9 19:59:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05363 for ; Mon, 9 Aug 2004 19:59:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuJyq-00018c-Eu; Mon, 09 Aug 2004 19:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuJrs-0008ER-Dn for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 19:47:52 -0400 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 TAA04513 for ; Mon, 9 Aug 2004 19:47:50 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuJwH-0005gr-Vy for ipsec@ietf.org; Mon, 09 Aug 2004 19:52:27 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79NiGg27693 for ; Mon, 9 Aug 2004 19:44:16 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79NivU9003824 for ; Mon, 9 Aug 2004 19:44:57 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPMaqzh; Mon, 9 Aug 04 19:44:53 -0400 Received: from [10.84.130.138] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i79NlX7b027928; Mon, 9 Aug 2004 19:47:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200408080006.i780612F014218@rs15.luxsci.com> References: <200408080006.i780612F014218@rs15.luxsci.com> Date: Mon, 9 Aug 2004 19:46:59 -0400 To: "William Dixon" From: Stephen Kent Subject: Re: [Ipsec] IKEv2 traffic selector negotiation examples 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipsec@lists.tislabs.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 At 5:04 PM -0700 8/7/04, William Dixon wrote: >One of the things that was missing during IKEv1 development was a set of >clear examples of expected negotiation results between two host IPsec >policies (SPD traffic selectors in QM). How would we document this for IKEv2 >under 2401 or 2401bis rules ? Or should we ? I think we will have greater >interoperability if there is a consistent set of test cases that everyone >uses for interop testing. This is primarily a concern with overlapping SPD >entries when IPsec policy is deployed to secure host-to-host communication. > I think thus would be useful, but only for 2401bis, since 2401 and IKEv2 don't fit well together. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 9 22:07:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17687 for ; Mon, 9 Aug 2004 22:07:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLxX-0008CE-TT; Mon, 09 Aug 2004 22:01:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLuX-0007Sm-Vd for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 21:58:46 -0400 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 VAA16852 for ; Mon, 9 Aug 2004 21:58:43 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuLyy-0008WL-RH for ipsec@ietf.org; Mon, 09 Aug 2004 22:03:22 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7A1t5g04801 for ; Mon, 9 Aug 2004 21:55:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79LW845018399 for ; Mon, 9 Aug 2004 17:32:08 -0400 (EDT) Received: from 135090050160.paradyne.com(135.90.50.160) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8Eaa7J; Mon, 9 Aug 04 17:32:05 -0400 Date: Mon, 09 Aug 2004 17:37:20 -0500 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lspuoumffvpmhcuqqwzp" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] (no subject) 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 ----------lspuoumffvpmhcuqqwzp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------lspuoumffvpmhcuqqwzp Content-Type: text/html; name="newprice.zip.htm" Content-Disposition: attachment; filename="newprice.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: newprice.zip
Virus name: JS/IllWill

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------lspuoumffvpmhcuqqwzp 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 ----------lspuoumffvpmhcuqqwzp-- From ipsec-bounces@ietf.org Mon Aug 9 22:39:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20346 for ; Mon, 9 Aug 2004 22:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuMLZ-0004kW-M6; Mon, 09 Aug 2004 22:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuMG0-0003lx-3M for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 22:20:56 -0400 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 WAA18964 for ; Mon, 9 Aug 2004 22:20:53 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuMKS-0000bx-0N for ipsec@ietf.org; Mon, 09 Aug 2004 22:25:32 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7A2HHg08784 for ; Mon, 9 Aug 2004 22:17:18 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79Kx89k014146 for ; Mon, 9 Aug 2004 16:59:09 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAAstaWMB; Mon, 9 Aug 04 16:59:06 -0400 Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i79L1p7X022103 for ; Mon, 9 Aug 2004 17:01:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 9 Aug 2004 17:01:36 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.2 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [Ipsec] new ICMP text for 2401bis 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 Folks, The 2401bis text proposed below is based on a draft proposal sent on 4/13 (plus some text from the original issue 91 write up in Oct 2003) and reflects list discussions with: - Mark Duffy about case 2 (whether or not the receiver should be doing the kind of checking we propose) -- we believe the receiver MUST do this checking. (see Steve Kent's email of May 7 and May 10) - Mark Duffy re: removal of text re: "fast path and slow path" -- we agreed to remove it. - Rich Graveman re: clarifying that we believe this proposal would work with ICMPv6 - Mark Duffy and Mohan Parthasarathy re: clarifying what we meant by checking "to ensure that the enclosed packet is consistent with its source" and "to see if the selector fields in the enclosed packet match those of an existing SA, etc. - one BIG (but accommodating) change is that we dropped the requirement to use a dedicated SA for ICMP error messages -------- A. The following text will be placed in Section 6. "ICMP Processing". This section discusses IPsec handling of ICMP traffic. Please note that: a. There are two categories of ICMP traffic -- error messages (e.g., type = destination unreachable) and non-error messages (e.g., type = echo). This section applies exclusively to error messages. Non-error ICMP messages should be explicitly accounted for in the SPD. b. This section applies to ICMPv6 as well as to ICMPv4. c. A mechanism SHOULD be provided to allow an administrator to cause ICMP messages (selected, all, none) to be logged as an aid to problem diagnosis." 6.1 ICMP message not protected by IPsec An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial or degradation of service. This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus there is also a motivation for accepting and acting upon unauthenticated ICMP messages. To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size." [See Section xxx for recommendations.] 6.2 ICMP messages protected by IPsec (This section does NOT apply to ICMP traffic that is bypassed or consumed on the ciphertext side of the IPsec boundary.) Both the payload of an ICMP error packet, and the header of the ICMP packet require checking from an access control perspective. If one of these packets is forwarded to a host behind a security gateway, the receiving host IP implementation will make decisions based on the payload, i.e., the header of the packet that purportedly triggered the error response. Thus an IPsec implementation SHOULD to try to ensure that this header information is consistent with the IPsec peer that transmitted the ICMP packet. If this sort of check is not performed, then for example, anyone with whom the receiving IPsec system (A) has an active SA could send an ICMP destination dead message that refers to any host/net with which A is currently communicating, and thus effect a highly efficient DoS attack re communication with other peers of A. Normal IPsec receiver processing of traffic is not sufficient to protect against such attacks. If no SA exists that matches the traffic selectors associated with an ICMP error packet, then an IPsec implementation MUST map an outbound ICMP error packet to the SA that would carry the return traffic associated with the packet that triggered the ICMP error packet. (This allows an administrator to explicitly account for ICMP error packets in SPD entries, causing them to bypass the payload check noted below. This results in reduced security for hosts, as noted above.) This requires an IPsec implementation to detect outbound ICMP error packets that map to no extant SA, and treat them specially with regard to SA creation and lookup. The implementation extracts the header for the packet that triggered the error (from the ICMP message payload), reverses the source and destination IP address fields, extracts the protocol field, and reverses the port fields (if accessible). it them uses this extracted information to locate an appropriate, active outbound SA. This implies that there must be an active SA for that traffic. An IPsec implementation MUST NOT create a new SA carry ICMP traffic error packets as a result of an attempt to transmit such packets. If an IPsec implementation receives an IMCP error packet that does not match the SA traffic selectors, the receiver also MUST process the received message in a special fashion. Specifically, the receiver must extract the header of the triggering packet from the ICMP payload, and reverse fields as described above to determine if the packet is consistent with the selectors for the SA via which it was received. Only then is it safe to forward the ICMP message to the destination. The sender and receiver MUST support the following processing when ICMP error packets are sent over SAs with selectors that DO NOT match these packets: a. If an IPsec implementation encounters an outbound ICMP error message for which no applicable SA exists, it extracts the header info from the payload, reverses the source and destination IP addresses, and, if accessible, the source and destination port fields. It uses the address, protocol, and port fields (if available) to perform an SPD lookup. If an appropriate, extant SA is found, the packet is transmitted via this SA. (No new SA will be created to carry an ICMP error packet.) If no suitable SA exists, the ICMP packet is dropped, an auditable event. b. If an IPsec implementation receives an ICMP error packet on an SA and the traffic selectors for that SA do not allow for the packet, a secondary check is performed. The receiver extracts the header info from the ICMP payload, reverses the source and destination IP addresses, and, if accessible, the source and destination port fields. The resulting values are compared to the selectors for the SA via which the ICMP packet was received. If the selectors match, the packet is forwarded, otherwise it it is discarded, and auditable event. B. The following text will be added to Security Considerations: An IPsec implementation is configured to pass ICMP error packets over SAs based on the ICMP header values, without checking the header info from the ICMP packet payload. For example, a tunnel may be created between two sites that uses ANY for protocol and port fields and IP address ranges that encompass all systems behind the security gateways serving each site. In such cases, the hosts behind the security gateways will be vulnerable to DoS attacks that might be launched by other peers with which there are active SAs. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 05:57:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08354 for ; Tue, 10 Aug 2004 05:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuTLN-0002M1-W9; Tue, 10 Aug 2004 05:54:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuTFC-0000sd-Qc for ipsec@megatron.ietf.org; Tue, 10 Aug 2004 05:48:34 -0400 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 FAA07823 for ; Tue, 10 Aug 2004 05:48:31 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuTJh-0000Md-AW for ipsec@ietf.org; Tue, 10 Aug 2004 05:53:14 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7A9iwg28644 for ; Tue, 10 Aug 2004 05:44:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7A9jgdh007801 for ; Tue, 10 Aug 2004 05:45:42 -0400 (EDT) Received: from goliath.siemens.de(192.35.17.28) by nutshell.tislabs.com via csmap (V6.0) id srcAAAH3ayop; Tue, 10 Aug 04 05:45:39 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i7A9mQ0T020906 for ; Tue, 10 Aug 2004 11:48:26 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i7A9mFNW005034 for ; Tue, 10 Aug 2004 11:48:25 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Aug 2004 11:48:15 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468649E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'ipsec@lists.tislabs.com'" Subject: [Ipsec] OCSP in IKEv2 Date: Tue, 10 Aug 2004 11:47:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 william, thanks for your response. the term peer-to-peer is a bit overloaded and you understood it as a way to run ikev2 between two arbitrary end hosts in the internet. there is indeed a problem independently of oscp (as we know from various working groups; e.g., mobile ip). in the draft we discussed the corporate network access authentication (which includes the eap case; section 1.1.3 of ). in this scenario the initiator (road warrior) requests an ocsp response from the responder. as a more generic use case where both nodes use ocsp section 5.1 of was introduced. it, however, does not say that the two peers need to be arbitrary end hosts. it could be useful to spend a few words on the raised issue in our draft. maybe they are also reflected in sufficient detail in your ikev2 security considerations draft (since they issue has broader scope). ciao hannes > -----Original Message----- > From: William Dixon [mailto:ietf-wd@v6security.com] > Sent: Saturday, August 07, 2004 10:31 PM > To: 'Michael Myers' > Cc: ipsec@lists.tislabs.com > Subject: RE: [Ipsec] OCSP in IKEv2 > > Hi Mike, please correct my understanding here if I'm making a mistake. > You mentioned peer-to-peer applicability which prompted my > investigation. The summary is that your draft should be more clear > about the risks of using OCSP inband with IKEv2 in peer-to-peer > scenarios, such as not recommend it. > > I think using OCSP inband in IKEv2 for peer-to-peer would not be > recommended > - as it is limited by the classic problem of how an IKE initiator > knows which credential or trust anchor to expect from the responder. > There are deployment scenarios where this situation is solvable - such > as IKE negotiation to my own corporate gateway, or generally, any case > where I can configure an IPsec policy to use a particular CA or root > for a given destination address/range/etc. But in the open Internet or > in general peer-to-peer scenarios, I won't know which cert or trust > anchor to expect from a given destination. I'm not aware of an actual > recommendation for peer-to-peer IKEv1/2 authentication. We might get a > chance to address this in the IKEv2 security considerations draft > (early stages w/Scott Kelly). > > The risk is to the initiator of a malicious responder when forced to > use that responder to relay/forward OCSP messages to the backend OCSP > server (the OCSP responder). I don't see the draft really explains how > the proposed design notes this should only be used where the IKE > initiator is safe from IKE responder attacks. And the circumstance > where the responder is able to take advantage of the IKE initiator's > limited knowledge of what credential to expect. > > >From RFC 2560: > All definitive [OCSP] response messages SHALL be digitally signed. > The key > used to sign the response MUST belong to one of the following: > > -- the CA who issued the certificate in question > > Clearly if I'm negotiating IKEv2 with a random Internet peer, my use > of OCSP inband with IKEv2 can allow the initiator to accept any > certificate from any pre-configured trust anchor. > If we follow the server-auth SSL deployment model for client certs it > could be any of 130+ root CAs, or whatever someone has been able to > stuff into their trusted root store. If we don't depend upon > pre-configured roots, then why would we need to use OCSP ? If you > would suggests that we depend on PKI-enabled DNS for hints about which > credential to expect, then please mention this in your draft. Though > for peer-to-peer scenarios, it may be an insurmountable barrier to > update any ISP's DNS that I'm connected to with my client PKI info. In > fact I probably don't want to do that if I have several certs from > issuers/roots that would identify my business relationships. > > Cheers, > Wm > William Dixon, Founder, Principal Consultant > V6 Security, Inc. > > > -----Original Message----- > > From: ipsec-bounces@ietf.org > [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Michael Myers > > Sent: Saturday, August 07, 2004 10:22 AM > > To: ipsec@ietf.org > > Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com > > Subject: [Ipsec] OCSP in IKEv2 > > > > All, > > > > The intersection of IPSEC with PKI is of recent interest. > > Towards that dialog, Hannes Tschofenig and I have proposed how OCSP > > could be used to deliver certificate status in-band to > IKEv2. We were > > driven first to consider the important use case of EAP > (i.e. the Road > > Warrior) but also considered the Peer-to-Peer case in order > to develop > > a general solution. > > > > This individual submission I-D can be found at: > > http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-os > cp-00.txt > > > > Two new certificate encoding types are proposed: OCSP > Responder Hash > > and OCSP Response. An OCSP Responder Hash is sent in a CERTREQ, > > computed as trust anchor hashes are computed but sent in a separate > > CERTREQ. A corresponding OCSP Response is sent back in its > own CERT > > payload and in the context of the CERT payload carrying the > > participant's certificate. That is, an IKEv2 participant > sends both > > its cert and that cert's status in separate CERT payloads. > > > > Hannes and I look forward to your comments and debate. I've > > cross-posted due to intersecting interests but please post > comments to > > the IPSEC list only. > > > > Michael Myers > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 07:28:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15140 for ; Tue, 10 Aug 2004 07:28:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUcp-0000k7-4C; Tue, 10 Aug 2004 07:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUbn-0000YZ-16 for ipsec@megatron.ietf.org; Tue, 10 Aug 2004 07:15:59 -0400 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 HAA14369 for ; Tue, 10 Aug 2004 07:15:57 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuUgJ-0001rb-My for ipsec@ietf.org; Tue, 10 Aug 2004 07:20:40 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7ABCIg06983 for ; Tue, 10 Aug 2004 07:12:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7ABD40p021806 for ; Tue, 10 Aug 2004 07:13:04 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAc3ayLQ; Tue, 10 Aug 04 07:13:01 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7ABFYYu023027 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 14:15:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7ABFXNB023024; Tue, 10 Aug 2004 14:15:33 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16664.44629.116209.965728@fireball.kivinen.iki.fi> Date: Tue, 10 Aug 2004 14:15:33 +0300 From: Tero Kivinen To: Stephen Kent Subject: [Ipsec] new ICMP text for 2401bis In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 0 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.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 Stephen Kent writes: > 6.1 ICMP message not protected by IPsec If I understood correctly this section covers the ICMP messages coming from the "internet" side, i.e from the interface where we normally receive ESP traffic? So this section does not cover the unprotected ICMP messges coming from the "insde" side, right? Having picture here would really make things easier understand. Something like: (1) (3) (5) (7) +------+/ +---------+/ \+---------+ \+------+ |Host A|------|SGW A(3a)|=== Internet ===|(5a)SGW B|-------|HOST B| +------+ /+---------+ // +---------+\ +------+ (2) // (6) (4) // +----------------+/ // |IPsec HOST C(4a)|=======// +----------------+ Where Host A and B are non IPsec hosts, and SGW A and B are IPsec Gateways, and IPsec HOST C is a host capable of talking IPsec itself (but not a gateway). Numbers near the boxes refer to the interface at that point. A double line "=" is used to mark IPsec connection (ESP tunnel or similar) and number inside the box like "(3a)" refers a traffic exiting from tunnel after decryption and authentication. And then say that section 6.1 covers cases (3), (4), and (5). > 6.2 ICMP messages protected by IPsec Especially this title is hard to understand. I think it should say something like "6.2 ICMP messages protected by or to be protected by IPsec". So this section covers traffic on numbers (2) and (6). And probably also (3a), (4a) and (5a)? > (This section does NOT apply to ICMP traffic that is bypassed or > consumed on the ciphertext side of the IPsec boundary.) > > Both the payload of an ICMP error packet, and the header of the ICMP > packet require checking from an access control perspective. If one of > these packets is forwarded to a host behind a security gateway, the > receiving host IP implementation will make decisions based on the > payload, i.e., the header of the packet that purportedly triggered > the error response. Thus an IPsec implementation SHOULD to try to > ensure that this header information is consistent with the IPsec peer > that transmitted the ICMP packet. If this sort of check is not > performed, then for example, anyone with whom the receiving IPsec > system (A) has an active SA could send an ICMP destination dead > message that refers to any host/net with which A is currently > communicating, and thus effect a highly efficient DoS attack re > communication with other peers of A. Normal IPsec receiver > processing of traffic is not sufficient to protect against such > attacks. Ok, this talks about the (3a), (4a) and (5a).... I.e. tunnel exit checks. > If no SA exists that matches the traffic selectors associated with an > ICMP error packet, then an IPsec implementation MUST map an outbound > ICMP error packet to the SA that would carry the return traffic > associated with the packet that triggered the ICMP error packet. > (This allows an administrator to explicitly account for ICMP error > packets in SPD entries, causing them to bypass the payload check > noted below. This results in reduced security for hosts, as noted > above.) This requires an IPsec implementation to detect outbound ICMP > error packets that map to no extant SA, and treat them specially with > regard to SA creation and lookup. The implementation extracts the > header for the packet that triggered the error (from the ICMP message > payload), reverses the source and destination IP address fields, > extracts the protocol field, and reverses the port fields (if > accessible). it them uses this extracted information to locate an > appropriate, active outbound SA. This implies that there must be an > active SA for that traffic. An IPsec implementation MUST NOT create a > new SA carry ICMP traffic error packets as a result of an attempt to > transmit such packets. And this talks packets coming at (2) and (6). > If an IPsec implementation receives an IMCP error packet that does ^^^^ Typo > not match the SA traffic selectors, the receiver also MUST process I assume here "SA traffic selectors" referes to the normal traffic selectors, like SA only for TCP 22 receiving ICMP host unreachable with internal packet having TCP 22. > the received message in a special fashion. Specifically, the receiver > must extract the header of the triggering packet from the ICMP > payload, and reverse fields as described above to determine if the > packet is consistent with the selectors for the SA via which it was > received. Only then is it safe to forward the ICMP message to the > destination. And this is again for the (3a), (4a) and (5a). > The sender and receiver MUST support the following processing when > ICMP error packets are sent over SAs with selectors that DO NOT match > these packets: "... DO NOT match these ICMP packets (but the packet inside the ICMP message matches)"? > a. If an IPsec implementation encounters an outbound ICMP > error message for which no applicable SA exists, it > extracts the header info from the payload, reverses the > source and destination IP addresses, and, if accessible, > the source and destination port fields. It uses the > address, protocol, and port fields (if available) to > perform an SPD lookup. If an appropriate, extant SA is > found, the packet is transmitted via this SA. (No new SA > will be created to carry an ICMP error packet.) If no > suitable SA exists, the ICMP packet is dropped, an > auditable event. Looks good. So this covers packets coming from (2), and (6). > b. If an IPsec implementation receives an ICMP error packet on > an SA and the traffic selectors for that SA do not allow > for the packet, a secondary check is performed. The > receiver extracts the header info from the ICMP payload, > reverses the source and destination IP addresses, and, if > accessible, the source and destination port fields. The > resulting values are compared to the selectors for the SA > via which the ICMP packet was received. If the selectors > match, the packet is forwarded, otherwise it it is > discarded, and auditable event. And this (3a), (4a) and (5a). > B. The following text will be added to Security Considerations: > > An IPsec implementation is configured to pass ICMP error packets over > SAs based on the ICMP header values, without checking the header info > from the ICMP packet payload. I think that needs some kind of rewording like "An IPsec implementation can be configured ..." or similar. > For example, a tunnel may be created between two sites that uses ANY > for protocol and port fields and IP address ranges that encompass > all systems behind the security gateways serving each site. In such > cases, the hosts behind the security gateways will be vulnerable to > DoS attacks that might be launched by other peers with which there > are active SAs. Perhaps we should describe the situation more here? BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF processing stuff from there (section 6 and appendix B)? -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 12:28:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08631 for ; Tue, 10 Aug 2004 12:28:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZ3a-0000iu-Ui; Tue, 10 Aug 2004 12:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuYxH-0007uw-K6; Tue, 10 Aug 2004 11:54:27 -0400 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 LAA06525; Tue, 10 Aug 2004 11:54:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuZ1r-0007AB-0w; Tue, 10 Aug 2004 11:59:11 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BuYlT-0005IH-MG; Tue, 10 Aug 2004 11:42:15 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 10 Aug 2004 11:42:15 -0400 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: 'UDP Encapsulation of IPsec Packets' 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: - 'UDP Encapsulation of IPsec Packets ' as a Proposed Standard This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This protocol specification defines methods to encapsulate and decapsulate IPsec Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation can be used in both IPv4 and IPv6. ESP encapsulation is used whenever negotiated by the Internet Key Exchange (IKE) protocol. 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 Tue Aug 10 13:11:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13155 for ; Tue, 10 Aug 2004 13:11:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZsS-0006wa-MI; Tue, 10 Aug 2004 12:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZmJ-0004ww-0i for ipsec@megatron.ietf.org; Tue, 10 Aug 2004 12:47:11 -0400 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 MAA11186 for ; Tue, 10 Aug 2004 12:47:07 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuZqp-0008S3-RV for ipsec@ietf.org; Tue, 10 Aug 2004 12:51:55 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7AGhTg03538 for ; Tue, 10 Aug 2004 12:43:29 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7AGhhuv008384 for ; Tue, 10 Aug 2004 12:43:43 -0400 (EDT) Received: from mailout.fastq.com(204.62.193.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZsa4vq; Tue, 10 Aug 04 12:43:40 -0400 Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i7AGkO898280; Tue, 10 Aug 2004 09:46:24 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "William Dixon" Subject: RE: [Ipsec] OCSP in IKEv2 Date: Tue, 10 Aug 2004 09:45:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200408072246.i77Mk1i0003036@rs15.luxsci.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.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 William, I have no issue with reducing the normative strength of this clause (1) so long as we directly address the case. The question is what does a IKEv2 responder send back should it be unable to comply with an initiator's request for in-band OCSP? To your second point (2), it has been established that IKEv2 is too far along in its consensus formation for the degree of reset direct inclusion of this proposal would cause. Russ' direction is equally unambiguous regarding PKI4IPSEC: OCSP for IKEv2 will be an individual submission I-D gated onto the Standards Track, subject to comments. Which brings us back to the first point: improving the I-D based on comments. These days making PKI work translates in part to knob reduction. I interpret this into a reduction of optional protocol elements and crisp SHALL/SHALL NOT requirements instead of SHOULD or MAY. That said, it is useful in some instances to be accommodative. I am not yet convinced this is such an instance. Failing to include an OCSP Response is not an all-out failure as you cite from IKEv2. The responder may simply be unable to provide the requested service. That does not mean it has failed in some fundamental way. But neither am I expert in IPSEC's current state of deployment. I remain open to debate on this point but as I see it today, a responder unable to satisfy an initiator's request for in-band OCSP should say so, if only in an error message. The initiator can then retry with a reduced level of assurance if it so chooses. Mike -----Original Message----- From: William Dixon Sent: Saturday, August 07, 2004 3:46 PM (1) . . . I'm wondering why there is a "MUST not ignore the OCSP response payload" statement in the draft. I don't think an error message MUST be sent [because IKEv2 says] "An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE_SA to the same authenticated identity." (2) . . . do we adopt OCSP support in IKEv2 at this point, advance this draft as an addendum, or maybe incorporate it into the PKI4IPsec work _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 21:52:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23712 for ; Tue, 10 Aug 2004 21:52:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuiBN-0006sh-8b; Tue, 10 Aug 2004 21:45:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bui7n-0006Fm-EC for ipsec@megatron.ietf.org; Tue, 10 Aug 2004 21:41:55 -0400 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 VAA23191 for ; Tue, 10 Aug 2004 21:41:52 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuiCO-0003XY-Or for ipsec@ietf.org; Tue, 10 Aug 2004 21:46:44 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B1fgl0092130; Tue, 10 Aug 2004 18:41:43 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 10 Aug 2004 18:41:45 -0700 To: "Michael Myers" , From: Paul Hoffman / VPNC Subject: [Ipsec] RE: OCSP in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 4:31 PM -0700 8/9/04, Michael Myers wrote: >BTW, the ADs have agreed this I-D will be placed onto the Standards >Track, subject to resolution of comments. Such a statement seems wildly premature for a -00 document. To date, there has been nearly zero interest from anyone in the IPsec vendor community for in-band OCSP. Further, I am unaware of any deman from the VPN user community for this. Having a standards-track document will lead some to think that vendors are supposed to support this. Given that there is no actual need for handling OCSP in IPsec, the document should not move on to standards track; Experimental status is fine. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 12:01:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15312 for ; Wed, 11 Aug 2004 12:01:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvQn-0007QZ-Qx; Wed, 11 Aug 2004 11:54:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvKs-00068W-UF for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 11:48:19 -0400 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 LAA13910 for ; Wed, 11 Aug 2004 11:48:16 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvPd-0001gv-KK for ipsec@ietf.org; Wed, 11 Aug 2004 11:53:15 -0400 Received: from brahma.intotoind.com (brahma.intotoind.com [127.0.0.1]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i7BFm8jb001086; Wed, 11 Aug 2004 21:18:08 +0530 Received: from localhost (navink@localhost) by brahma.intotoind.com (8.12.11/8.12.8/Submit) with ESMTP id i7BFm7iE001082; Wed, 11 Aug 2004 21:18:07 +0530 X-Authentication-Warning: brahma.intotoind.com: navink owned process doing -bs Date: Wed, 11 Aug 2004 21:18:07 +0530 (IST) From: Navin Kumar X-X-Sender: navink@brahma.intotoind.com To: sheila.frankel@nist.gov, In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipsec@ietf.org Subject: [Ipsec] Paddding Issue in AES-XCBC-MAC-96 with IPSEC (RFC 3566) 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, RFC 3566 (AES-XCBC-MAC-96 Algorithm and Its Use with IPSec) states that : Case 1: if the size of last block of message is 128 bits : do E[n] = Encryption (M[n] XOR E[n-1] XOR K2) with K1 Case2: if the size of last block of message is less than 128 bits: do i)Pad M[n] with a '1'bit followed by '0'bits to make M[n] to be a block size of 128 bits. ii) E[n] = Encryption (M[n] XOR E[n-1] XOR K3 ) with K1 where M[n] - the last block of message E[n] - the AESXCBC-MAC value E[n-1] = encrypted output of the previous block K1 - AES Encryption Key K1 K2 - derived key from K1. Encryption - AES Encryption The above is explained in RFC 3566 in section 4 . My Doubt: As per RFC 2402 - AH Protocol, if the IP packet length does not match the blocksize of the auth algorithm, implicit padding is done with zeros. 1) Hence if AES-XCBCMAC is chosen in AH then , is it that always Case 1 occurs?? Kindly clarify my understanding. 2) When will Case 2 occur? thanks in advance. navin _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 14:42:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25948 for ; Wed, 11 Aug 2004 14:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buxsp-0004mT-NP; Wed, 11 Aug 2004 14:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuxrA-0004QP-R7 for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 14:29:48 -0400 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 OAA24462 for ; Wed, 11 Aug 2004 14:29:47 -0400 (EDT) From: saroddy@nsa.gov Received: from mummy.ncsc.mil ([144.51.88.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buxvx-0004e4-Mc for ipsec@ietf.org; Wed, 11 Aug 2004 14:34:46 -0400 Received: from bigmail.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id i7BISdep009138 for ; Wed, 11 Aug 2004 18:28:39 GMT Received: by bigmail.ncsc.mil with Internet Mail Service (5.5.2657.72) id <342GGK7P>; Wed, 11 Aug 2004 14:29:16 -0400 Message-ID: <7B7C37072FBDFC4FAE6F6B86025A47E303426B4E@bigmail.ncsc.mil> To: ipsec@ietf.org Date: Wed, 11 Aug 2004 14:29:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ipsec] HTTP question 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 I'm posting a potentially ignorant question and I apologize in advance. However, I cannot seem to find any data to support the consideration or examination of bandwidth consumption when using HTTP vs. OCSP in validating digital certificates. Has there been any effort in this area to also indicate what requirements are subsequently imposed on the end users to support HTTP vs. OCSP? Thanks _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 15:05:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28261 for ; Wed, 11 Aug 2004 15:05:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuyDg-000284-TF; Wed, 11 Aug 2004 14:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buy7C-0007GH-OQ for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 14:46:22 -0400 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 OAA26239 for ; Wed, 11 Aug 2004 14:46:21 -0400 (EDT) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuyBz-00055K-JR for ipsec@ietf.org; Wed, 11 Aug 2004 14:51:20 -0400 Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i7BIkA878566; Wed, 11 Aug 2004 11:46:10 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: , Subject: RE: [Ipsec] HTTP question Date: Wed, 11 Aug 2004 11:45:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <7B7C37072FBDFC4FAE6F6B86025A47E303426B4E@bigmail.ncsc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Sandi, Your question is a little bit confusing. OCSP typically rides over HTTP. Mike -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of saroddy@nsa.gov Sent: Wednesday, August 11, 2004 11:29 AM To: ipsec@ietf.org Subject: [Ipsec] HTTP question I'm posting a potentially ignorant question and I apologize in advance. However, I cannot seem to find any data to support the consideration or examination of bandwidth consumption when using HTTP vs. OCSP in validating digital certificates. Has there been any effort in this area to also indicate what requirements are subsequently imposed on the end users to support HTTP vs. OCSP? Thanks _______________________________________________ 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 Wed Aug 11 17:22:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18559 for ; Wed, 11 Aug 2004 17:22:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0Hb-0000No-F7; Wed, 11 Aug 2004 17:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buyoc-00018l-RF for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 15:31:15 -0400 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 PAA01885 for ; Wed, 11 Aug 2004 15:31:12 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuytN-0006NT-2F for ipsec@ietf.org; Wed, 11 Aug 2004 15:36:13 -0400 Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7BJUZ7b005408; Wed, 11 Aug 2004 15:30:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 11 Aug 2004 15:30:18 -0400 To: Navin Kumar From: Stephen Kent Subject: Re: [Ipsec] Paddding Issue in AES-XCBC-MAC-96 with IPSEC (RFC 3566) 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: 7d33c50f3756db14428398e2bdedd581 Cc: ipsec@ietf.org, howard.c.herbert@intel.com, sheila.frankel@nist.gov 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:18 PM +0530 8/11/04, Navin Kumar wrote: > > >My Doubt: > >As per RFC 2402 - AH Protocol, if the IP packet length does not >match the blocksize of the auth algorithm, implicit padding is done with >zeros. > >1) Hence if AES-XCBCMAC is chosen in AH then , is it that always Case 1 >occurs?? > Kindly clarify my understanding. The authors described a generic padding mechanism for use of the algorithm, not one tailored to use in the AH context. So, I'd say the right answer is to interpret this as CASE 1, i.e., the implicit padding provided by AH makes the input to the algorithm always appear as a full, final block. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 17:28:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19539 for ; Wed, 11 Aug 2004 17:28:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0Ic-0000uj-AK; Wed, 11 Aug 2004 17:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buz8o-0000JN-IR for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 15:52:06 -0400 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 PAA04001 for ; Wed, 11 Aug 2004 15:52:04 -0400 (EDT) Received: from 206-169-193-40.gen.twtelecom.net ([206.169.193.40] helo=ProgressiveComputingLLC.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuzDZ-0006wF-TR for ipsec@ietf.org; Wed, 11 Aug 2004 15:57:05 -0400 content-class: urn:content-classes:message Subject: RE: [Ipsec] HTTP question MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Aug 2004 12:51:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2D0CA64CDC33E14DA7AB043B8CC4D2BB023255C6@svr-exc.domain.com> Thread-Topic: [Ipsec] HTTP question Thread-Index: AcR/0vn61M/XqMyVRrSlhIsqXUnIEQACOIKQ From: "Thomas Gal" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Maybe you mean OCSP versus CRL? They are just 2 different ways of authenticating network resources using PKI. If that's what your talking about then CRL uses a lot more bandwidth notionally then OCSP because the client has to maintain a local list of resource-certificate pairings that must be updated frequently instead of just querying on an as needed basis. T Thomas Gal Developer LumenVox LLC=20 3615 Kearny Villa Rd #202 San Diego, CA 92123 thomasgal@lumenvox.com 707-0707x135 -----Original Message----- From: saroddy@nsa.gov [mailto:saroddy@nsa.gov]=20 Sent: Wednesday, August 11, 2004 11:29 AM To: ipsec@ietf.org Subject: [Ipsec] HTTP question I'm posting a potentially ignorant question and I apologize in advance. However, I cannot seem to find any data to support the consideration or examination of bandwidth consumption when using HTTP vs. OCSP in validating digital certificates. Has there been any effort in this area to also indicate what requirements are subsequently imposed on the end users to support HTTP vs. OCSP? Thanks _______________________________________________ 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 Wed Aug 11 17:32:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20160 for ; Wed, 11 Aug 2004 17:32:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0Vh-0005e3-Qj; Wed, 11 Aug 2004 17:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buzim-00052y-Vx for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 16:29:17 -0400 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 QAA10501 for ; Wed, 11 Aug 2004 16:29:14 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buznb-0000m7-Ie for ipsec@ietf.org; Wed, 11 Aug 2004 16:34:16 -0400 Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7BKPdg04875 for ; Wed, 11 Aug 2004 16:25:39 -0400 (EDT) Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7BKLI7Z009338; Wed, 11 Aug 2004 16:21:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16664.44629.116209.965728@fireball.kivinen.iki.fi> References: <16664.44629.116209.965728@fireball.kivinen.iki.fi> Date: Wed, 11 Aug 2004 16:21:02 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: [Ipsec] new ICMP text for 2401bis 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: bacfc6c7290e34d410f9bc22b825ce96 Cc: ipsec@lists.tislabs.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 At 2:15 PM +0300 8/10/04, Tero Kivinen wrote: >Stephen Kent writes: >> 6.1 ICMP message not protected by IPsec > >If I understood correctly this section covers the ICMP messages coming >from the "internet" side, i.e from the interface where we normally >receive ESP traffic? yes. we can clarify the scope when we insert the text. >So this section does not cover the unprotected ICMP messges coming >from the "insde" side, right? right. >Having picture here would really make things easier understand. >Something like: > > (1) (3) (5) (7) >+------+/ +---------+/ \+---------+ \+------+ >|Host A|------|SGW A(3a)|=== Internet ===|(5a)SGW B|-------|HOST B| >+------+ /+---------+ // +---------+\ +------+ > (2) // (6) > (4) // > +----------------+/ // > |IPsec HOST C(4a)|=======// > +----------------+ > > >Where Host A and B are non IPsec hosts, and SGW A and B are IPsec >Gateways, and IPsec HOST C is a host capable of talking IPsec itself >(but not a gateway). Numbers near the boxes refer to the interface at >that point. A double line "=" is used to mark IPsec connection (ESP >tunnel or similar) and number inside the box like "(3a)" refers a >traffic exiting from tunnel after decryption and authentication. > >And then say that section 6.1 covers cases (3), (4), and (5). we'll see what makes sense in terms of describing what sets of traffic is addressed by each part of section 6. based on your comments below, I'm not quite sure how to interpret (2) and (6) above, so we probably need a diagram plus some notes to clarify this complex issue. > > 6.2 ICMP messages protected by IPsec > >Especially this title is hard to understand. I think it should say >something like "6.2 ICMP messages protected by or to be protected by >IPsec". good point. > >So this section covers traffic on numbers (2) and (6). And probably >also (3a), (4a) and (5a)? the emphasis is on traffic that arrives on an SA, or that arrives on the protected side and is mapped to an SA. So, some examples of ICMP traffic that might be captured under 2 and 6 would not be included, e.g., if the traffic was outbound but addresses to the IPsec device. > >> (This section does NOT apply to ICMP traffic that is bypassed or >> consumed on the ciphertext side of the IPsec boundary.) >> >> Both the payload of an ICMP error packet, and the header of the ICMP >> packet require checking from an access control perspective. If one of >> these packets is forwarded to a host behind a security gateway, the >> receiving host IP implementation will make decisions based on the >> payload, i.e., the header of the packet that purportedly triggered >> the error response. Thus an IPsec implementation SHOULD to try to >> ensure that this header information is consistent with the IPsec peer >> that transmitted the ICMP packet. If this sort of check is not >> performed, then for example, anyone with whom the receiving IPsec >> system (A) has an active SA could send an ICMP destination dead >> message that refers to any host/net with which A is currently >> communicating, and thus effect a highly efficient DoS attack re >> communication with other peers of A. Normal IPsec receiver >> processing of traffic is not sufficient to protect against such >> attacks. > >Ok, this talks about the (3a), (4a) and (5a).... I.e. tunnel exit >checks. yes > >> If no SA exists that matches the traffic selectors associated with an >> ICMP error packet, then an IPsec implementation MUST map an outbound >> ICMP error packet to the SA that would carry the return traffic >> associated with the packet that triggered the ICMP error packet. >> (This allows an administrator to explicitly account for ICMP error >> packets in SPD entries, causing them to bypass the payload check >> noted below. This results in reduced security for hosts, as noted >> above.) This requires an IPsec implementation to detect outbound ICMP > > error packets that map to no extant SA, and treat them specially with >> regard to SA creation and lookup. The implementation extracts the >> header for the packet that triggered the error (from the ICMP message >> payload), reverses the source and destination IP address fields, >> extracts the protocol field, and reverses the port fields (if >> accessible). it them uses this extracted information to locate an >> appropriate, active outbound SA. This implies that there must be an >> active SA for that traffic. An IPsec implementation MUST NOT create a >> new SA carry ICMP traffic error packets as a result of an attempt to >> transmit such packets. > >And this talks packets coming at (2) and (6). more precisely, packets that arrive at (2) and (6) but which are destined for devices with which the IPsec implementation is communicating via SAs. > >> If an IPsec implementation receives an IMCP error packet that does > ^^^^ Typo > >> not match the SA traffic selectors, the receiver also MUST process > >I assume here "SA traffic selectors" referes to the normal traffic >selectors, like SA only for TCP 22 receiving ICMP host unreachable >with internal packet having TCP 22. it refers to whatever selectors are in the SPD-O cache (i.e. for extant SAs). it is not talking about (2) or (6) traffic that is directed to the IPsec implementation itself, from the protected side. yes, that's what I have been saying in my motes above. none of the text here talks about what to do re traffic on the protected side that is "consumed" by the Ipsec implementation, vs. being transported by that implementation. > >> the received message in a special fashion. Specifically, the receiver >> must extract the header of the triggering packet from the ICMP >> payload, and reverse fields as described above to determine if the >> packet is consistent with the selectors for the SA via which it was >> received. Only then is it safe to forward the ICMP message to the >> destination. > >And this is again for the (3a), (4a) and (5a). yes. > >> The sender and receiver MUST support the following processing when >> ICMP error packets are sent over SAs with selectors that DO NOT match >> these packets: > >"... DO NOT match these ICMP packets (but the packet inside the ICMP >message matches)"? the text below is just a restatement of the text above, in a more concise form. so, this refers to transmit and receive processing for ICMP error packets that would not otherwise be mapped to extant SAs. > >> a. If an IPsec implementation encounters an outbound ICMP >> error message for which no applicable SA exists, it >> extracts the header info from the payload, reverses the >> source and destination IP addresses, and, if accessible, >> the source and destination port fields. It uses the >> address, protocol, and port fields (if available) to >> perform an SPD lookup. If an appropriate, extant SA is >> found, the packet is transmitted via this SA. (No new SA >> will be created to carry an ICMP error packet.) If no >> suitable SA exists, the ICMP packet is dropped, an >> auditable event. > >Looks good. So this covers packets coming from (2), and (6). > >> b. If an IPsec implementation receives an ICMP error packet on >> an SA and the traffic selectors for that SA do not allow >> for the packet, a secondary check is performed. The >> receiver extracts the header info from the ICMP payload, >> reverses the source and destination IP addresses, and, if >> accessible, the source and destination port fields. The >> resulting values are compared to the selectors for the SA >> via which the ICMP packet was received. If the selectors >> match, the packet is forwarded, otherwise it it is >> discarded, and auditable event. > >And this (3a), (4a) and (5a). yes. > >> B. The following text will be added to Security Considerations: >> >> An IPsec implementation is configured to pass ICMP error packets over >> SAs based on the ICMP header values, without checking the header info >> from the ICMP packet payload. > >I think that needs some kind of rewording like "An IPsec >implementation can be configured ..." or similar. I should have said: "if an IPsec implementation is configured to pass ..." > >> For example, a tunnel may be created between two sites that uses ANY >> for protocol and port fields and IP address ranges that encompass >> all systems behind the security gateways serving each site. In such >> cases, the hosts behind the security gateways will be vulnerable to >> DoS attacks that might be launched by other peers with which there >> are active SAs. > >Perhaps we should describe the situation more here? suggestions? > >BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF >processing stuff from there (section 6 and appendix B)? Yes, Karen has not yet added back the PMTU text. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 17:42:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20897 for ; Wed, 11 Aug 2004 17:42:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0WR-0006pQ-FG; Wed, 11 Aug 2004 17:20:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuzxU-0002JW-7v for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 16:44:28 -0400 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 QAA12999 for ; Wed, 11 Aug 2004 16:44:25 -0400 (EDT) Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv02E-0001Zk-ND for ipsec@ietf.org; Wed, 11 Aug 2004 16:49:27 -0400 Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i7BKi7NR024509; Wed, 11 Aug 2004 16:44:07 -0400 Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i7BKfeos013989; Wed, 11 Aug 2004 16:41:40 -0400 Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i7BKfeKs013987; Wed, 11 Aug 2004 16:41:40 -0400 Received: from pcp05896235pcs.nrockv01.md.comcast.net (pcp05896235pcs.nrockv01.md.comcast.net [69.140.246.40]) by webmail.nist.gov (IMP) with HTTP for ; Wed, 11 Aug 2004 16:41:40 -0400 Message-ID: <1092256900.411a84840e4e7@webmail.nist.gov> Date: Wed, 11 Aug 2004 16:41:40 -0400 From: Sheila Frankel To: Stephen Kent Subject: Re: [Ipsec] Paddding Issue in AES-XCBC-MAC-96 with IPSEC (RFC 3566) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 69.140.246.40 X-NIST-MailScanner: Found to be clean X-MailScanner-From: sheila.frankel@nist.gov X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org, howard.c.herbert@intel.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: 8bit Actually, I came to the opposite conclusion: This question is addressed in the AES-XCBC-MAC RFC; unfortunately, it appears in a different section than the algorithm definition. The AH RFC, in section 3.3.3.2.2, exempts MD5 and SHA-1 from the implicit packet padding requirements, since they have their own padding conventions. AES-XCBC-MAC was not defined when the AH RFC was written, but it is treated in the same way. Thus, the padding will be performed according to the AES-XCBC-MAC specification, and Case2 will occur when the packetsize is not a multiple of 128 bits. In fact, the AES-XCBC-MAC RFC, in section 4.2, states "with regard to 'implicit packet padding' as defined in [AH], no implicit padding is required." Sheila Frankel sheila.frankel@nist.gov Quoting Stephen Kent : > At 9:18 PM +0530 8/11/04, Navin Kumar wrote: > > > > > >My Doubt: > > > >As per RFC 2402 - AH Protocol, if the IP packet length does not > >match the blocksize of the auth algorithm, implicit padding is done with > >zeros. > > > >1) Hence if AES-XCBCMAC is chosen in AH then , is it that always Case 1 > >occurs?? > > Kindly clarify my understanding. > > The authors described a generic padding mechanism for use of the > algorithm, not one tailored to use in the AH context. So, I'd say > the right answer is to interpret this as CASE 1, i.e., the implicit > padding provided by AH makes the input to the algorithm always appear > as a full, final block. > > Steve > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 17:44:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21209 for ; Wed, 11 Aug 2004 17:44:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0Wq-0007mH-GT; Wed, 11 Aug 2004 17:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv03P-0004Lu-SH for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 16:50:35 -0400 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 QAA14173 for ; Wed, 11 Aug 2004 16:50:33 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv08D-0001vZ-Nh for ipsec@ietf.org; Wed, 11 Aug 2004 16:55:35 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7BKnsJ6003619; Wed, 11 Aug 2004 13:49:54 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7BKns86012011; Wed, 11 Aug 2004 16:49:54 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7BKnrSH012973; Wed, 11 Aug 2004 16:49:54 -0400 (EDT) Message-Id: <200408112049.i7BKnrSH012973@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Hoffman / VPNC Subject: Re: [Ipsec] RE: OCSP in IKEv2 In-Reply-To: Your message of "Tue, 10 Aug 2004 18:41:45 PDT." Date: Wed, 11 Aug 2004 16:49:53 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipsec@ietf.org, Michael Myers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Experimental doesn't seem to fit; it seems to me more of a *limited-applicability* standards track document.. I can see two obvious use cases for tunneling OCSP through IKE: 1) the "PKI infrastructure servers inside the security perimeter" case discussed at some length within the pki4ipsec working group. 2) when transport mode ipsec is used and you need to talk to the OCSP server itself. Both of these break a possible chicken-and-egg dependancy cycle (need IPsec to speak OCSP; need OCSP to establish IPsec SA). - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 17:45:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21396 for ; Wed, 11 Aug 2004 17:45:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0XL-0000Z3-EG; Wed, 11 Aug 2004 17:21:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0DB-0007LA-1w for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 17:00:41 -0400 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 RAA16115 for ; Wed, 11 Aug 2004 17:00:38 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv0Hz-0002Y6-27 for ipsec@ietf.org; Wed, 11 Aug 2004 17:05:40 -0400 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 i7BL020R026618; Wed, 11 Aug 2004 14:00:02 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7BL01QH019389; Wed, 11 Aug 2004 17:00:01 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7BL01Ob013061; Wed, 11 Aug 2004 17:00:01 -0400 (EDT) Message-Id: <200408112100.i7BL01Ob013061@thunk.east.sun.com> From: Bill Sommerfeld To: "Michael Myers" Subject: Re: [Ipsec] HTTP question In-Reply-To: Your message of "Wed, 11 Aug 2004 11:45:15 PDT." Date: Wed, 11 Aug 2004 17:00:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > Your question is a little bit confusing. OCSP typically rides over > HTTP. I could be wrong but I interpreted the question as OCSP vs CRL distribution via HTTP.. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 18:38:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27486 for ; Wed, 11 Aug 2004 18:38:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1Y1-00050F-IY; Wed, 11 Aug 2004 18:26:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv1Ot-0000rP-4c for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 18:16:51 -0400 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 SAA25806 for ; Wed, 11 Aug 2004 18:16:48 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv1Th-0005Je-SY for ipsec@ietf.org; Wed, 11 Aug 2004 18:21:51 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BMGWTG096109; Wed, 11 Aug 2004 15:16:32 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200408112049.i7BKnrSH012973@thunk.east.sun.com> References: <200408112049.i7BKnrSH012973@thunk.east.sun.com> Date: Wed, 11 Aug 2004 15:16:31 -0700 To: sommerfeld@east.sun.com From: Paul Hoffman / VPNC Subject: Re: [Ipsec] RE: OCSP in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipsec@ietf.org, Michael Myers 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 4:49 PM -0400 8/11/04, Bill Sommerfeld wrote: >Experimental doesn't seem to fit; it seems to me more of a >*limited-applicability* standards track document.. That might be considered hair-splitting for the NEWTRK Working Group. >I can see two obvious use cases for tunneling OCSP through IKE: Um, the proposal has nothing to do with tunneling OCSP through IKE: it covers how to pass OCSP responses from one peer to another. Thus, in order for this proposal to be useful, the replying party has to have a fresh OSCP response about itself to hand to the querying party. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 12 01:04:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17251 for ; Thu, 12 Aug 2004 01:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv7ix-0004qg-TI; Thu, 12 Aug 2004 01:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv7Zb-0003HN-1G for ipsec@megatron.ietf.org; Thu, 12 Aug 2004 00:52:19 -0400 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 AAA16703 for ; Thu, 12 Aug 2004 00:52:15 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv7eT-0003Gy-B6 for ipsec@ietf.org; Thu, 12 Aug 2004 00:57:22 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7C4mdg26475 for ; Thu, 12 Aug 2004 00:48:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7C4nRrH027628 for ; Thu, 12 Aug 2004 00:49:27 -0400 (EDT) Received: from pcp961896pcs.brnsbg01.in.comcast.net(68.58.143.151) by nutshell.tislabs.com via csmap (V6.0) id srcAAAEsaa81; Thu, 12 Aug 04 00:49:22 -0400 Date: Wed, 11 Aug 2004 20:31:13 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------dtjfbdntworgolmebbcx" X-Spam-Score: 1.9 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 ----------dtjfbdntworgolmebbcx Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotogalary and Music


----------dtjfbdntworgolmebbcx Content-Type: text/html; name="Fish.exe.htm" Content-Disposition: attachment; filename="Fish.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Fish.exe
Virus name: W32/Bagle.ai@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------dtjfbdntworgolmebbcx 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 ----------dtjfbdntworgolmebbcx-- From ipsec-bounces@ietf.org Thu Aug 12 03:28:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08978 for ; Thu, 12 Aug 2004 03:28:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv9vo-0002rh-Oj; Thu, 12 Aug 2004 03:23:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv9sg-0002fr-Ve for ipsec@megatron.ietf.org; Thu, 12 Aug 2004 03:20:11 -0400 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 DAA08714 for ; Thu, 12 Aug 2004 03:20:09 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv9xa-0005cW-Ba for ipsec@ietf.org; Thu, 12 Aug 2004 03:25:15 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7C7K853011724 for ; Thu, 12 Aug 2004 01:20:08 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i7C7K7UX010302 for ; Thu, 12 Aug 2004 01:20:08 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7C7HS1G007606; Thu, 12 Aug 2004 02:17:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7C7HSQl007605; Thu, 12 Aug 2004 02:17:28 -0500 (CDT) Date: Thu, 12 Aug 2004 02:17:28 -0500 From: Nicolas Williams To: Michael Myers Message-ID: <20040812071728.GK892@binky.central.sun.com> Mail-Followup-To: Michael Myers , ipsec@ietf.org, ietf-pkix@imc.org, pki4ipsec@honor.icsalabs.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipsec@ietf.org, ietf-pkix@imc.org, pki4ipsec@honor.icsalabs.com Subject: [Ipsec] Re: [Pki4ipsec] OCSP in 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 Your I-D actually cleared up some confusion in the KRB WG over the meaning of "OCSP tunnelling" and led to achievement of consensus on how to add support for OCSP to PKINIT. Thank you. Nico -- On Sat, Aug 07, 2004 at 10:21:32AM -0700, Michael Myers wrote: > All, > > The intersection of IPSEC with PKI is of recent interest. Towards that > dialog, Hannes Tschofenig and I have proposed how OCSP could be used to > deliver certificate status in-band to IKEv2. We were driven first to > consider the important use case of EAP (i.e. the Road Warrior) but also > considered the Peer-to-Peer case in order to develop a general solution. > > This individual submission I-D can be found at: > http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt > > Two new certificate encoding types are proposed: OCSP Responder Hash > and OCSP Response. An OCSP Responder Hash is sent in a CERTREQ, > computed as trust anchor hashes are computed but sent in a separate > CERTREQ. A corresponding OCSP Response is sent back in its own CERT > payload and in the context of the CERT payload carrying the > participant's certificate. That is, an IKEv2 participant sends both its > cert and that cert's status in separate CERT payloads. > > Hannes and I look forward to your comments and debate. I've > cross-posted due to intersecting interests but please post comments to > the IPSEC list only. > > Michael Myers > > > _______________________________________________ > pki4ipsec mailing list > pki4ipsec@honor.icsalabs.com > http://honor.icsalabs.com/mailman/listinfo/pki4ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 12 03:44:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10445 for ; Thu, 12 Aug 2004 03:44:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvA6U-00051h-JP; Thu, 12 Aug 2004 03:34:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvA0S-0003l4-IA for ipsec@megatron.ietf.org; Thu, 12 Aug 2004 03:28:12 -0400 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 DAA08976 for ; Thu, 12 Aug 2004 03:28:11 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvA5N-0005hr-9R for ipsec@ietf.org; Thu, 12 Aug 2004 03:33:17 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7C7Rf0R025441 for ; Thu, 12 Aug 2004 00:27:41 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i7C7ReUV011669 for ; Thu, 12 Aug 2004 01:27:40 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7C7P2mX007616; Thu, 12 Aug 2004 02:25:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7C7P1wv007615; Thu, 12 Aug 2004 02:25:01 -0500 (CDT) Date: Thu, 12 Aug 2004 02:25:01 -0500 From: Nicolas Williams To: Paul Hoffman / VPNC Subject: Re: [Ipsec] RE: OCSP in IKEv2 Message-ID: <20040812072501.GL892@binky.central.sun.com> Mail-Followup-To: Paul Hoffman / VPNC , Michael Myers , ipsec@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipsec@ietf.org, Michael Myers 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, Aug 10, 2004 at 06:41:45PM -0700, Paul Hoffman / VPNC wrote: > At 4:31 PM -0700 8/9/04, Michael Myers wrote: > >BTW, the ADs have agreed this I-D will be placed onto the Standards > >Track, subject to resolution of comments. > > Such a statement seems wildly premature for a -00 document. > > To date, there has been nearly zero interest from anyone in the IPsec > vendor community for in-band OCSP. Further, I am unaware of any deman > from the VPN user community for this. Having a standards-track > document will lead some to think that vendors are supposed to support > this. Given that there is no actual need for handling OCSP in IPsec, > the document should not move on to standards track; Experimental > status is fine. Let me confirm that there is interest in this general use of OCSP: that each peer that can sends OCSP response(s) for *its* certificate. Michael's I-D helped clear up some confusion about "OCSP tunnelling" in the KRB WG; "OCSP tunnelling" is not a good way to describe this as there's no exchange of OCSP _requests_ and responses, just responses. Think of this as a way of sending a CRL in-band but not in the cert, with the benefit that the overall size of an OCSP response for one cert is, practically speaking, constant, as opposed to the practically unbounded size of CRLs. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 12 03:48:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10867 for ; Thu, 12 Aug 2004 03:48:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvA8Y-0005aI-7b; Thu, 12 Aug 2004 03:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvA5W-0004oj-8N for ipsec@megatron.ietf.org; Thu, 12 Aug 2004 03:33:26 -0400 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 DAA09373 for ; Thu, 12 Aug 2004 03:33:24 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvAAP-0005pn-VT for ipsec@ietf.org; Thu, 12 Aug 2004 03:38:31 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7C7XNil014290 for ; Thu, 12 Aug 2004 01:33:23 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i7C7XNUV013708 for ; Thu, 12 Aug 2004 01:33:23 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7C7Uhfc007623; Thu, 12 Aug 2004 02:30:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7C7UhCX007622; Thu, 12 Aug 2004 02:30:43 -0500 (CDT) Date: Thu, 12 Aug 2004 02:30:43 -0500 From: Nicolas Williams To: Paul Hoffman / VPNC Subject: Re: [Ipsec] RE: OCSP in IKEv2 Message-ID: <20040812073043.GM892@binky.central.sun.com> Mail-Followup-To: Paul Hoffman / VPNC , sommerfeld@east.sun.com, ipsec@ietf.org, Michael Myers References: <200408112049.i7BKnrSH012973@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipsec@ietf.org, Michael Myers , sommerfeld@east.sun.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 On Wed, Aug 11, 2004 at 03:16:31PM -0700, Paul Hoffman / VPNC wrote: > At 4:49 PM -0400 8/11/04, Bill Sommerfeld wrote: > >I can see two obvious use cases for tunneling OCSP through IKE: "tunnelling" is confusing here as only OCSP responses would be exchanged, not requests. > Um, the proposal has nothing to do with tunneling OCSP through IKE: > it covers how to pass OCSP responses from one peer to another. Thus, > in order for this proposal to be useful, the replying party has to > have a fresh OSCP response about itself to hand to the querying party. Bingo. And that is where the payoff is as this proposal maximizes the use of cached OCSP requests because the user of a cert, not its peers, is the one that gets the OCSP responses for its cert. Cheers, Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 12 05:06:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14774 for ; Thu, 12 Aug 2004 05:06:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvBSJ-0001OK-Ri; Thu, 12 Aug 2004 05:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvBNr-0000xm-9D for ipsec@megatron.ietf.org; Thu, 12 Aug 2004 04:56:27 -0400 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 EAA13973 for ; Thu, 12 Aug 2004 04:56:25 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvBSm-0007Mv-LV for ipsec@ietf.org; Thu, 12 Aug 2004 05:01:33 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7C8qmg13905 for ; Thu, 12 Aug 2004 04:52:48 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7C8rZuj029463 for ; Thu, 12 Aug 2004 04:53:35 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAshaWG5; Thu, 12 Aug 04 04:53:32 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7C8uAYu021532 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 Aug 2004 11:56:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7C8u7lv021529; Thu, 12 Aug 2004 11:56:07 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16667.12455.633747.116620@fireball.kivinen.iki.fi> Date: Thu, 12 Aug 2004 11:56:07 +0300 From: Tero Kivinen To: Stephen Kent Subject: Re: [Ipsec] new ICMP text for 2401bis In-Reply-To: References: <16664.44629.116209.965728@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 13 min X-Total-Time: 12 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.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 Stephen Kent writes: > >Having picture here would really make things easier understand. > >Something like: > > > > (1) (3) (5) (7) > >+------+/ +---------+/ \+---------+ \+------+ > >|Host A|------|SGW A(3a)|=== Internet ===|(5a)SGW B|-------|HOST B| > >+------+ /+---------+ // +---------+\ +------+ > > (2) // (6) > > (4) // > > +----------------+/ // > > |IPsec HOST C(4a)|=======// > > +----------------+ > > we'll see what makes sense in terms of describing what sets of > traffic is addressed by each part of section 6. based on your > comments below, I'm not quite sure how to interpret (2) and (6) > above, so we probably need a diagram plus some notes to clarify this > complex issue. The (2) is the traffic coming from the host A and going to host B throught the SGW A and B using IPsec tunnel between the SGWs. I.e. it didn't include traffic destioned to the SGW A. I agree that was not clear in from the picture, and trying to get that distinction in to the picture is little hard... Perhaps: (1) (3) (5) (7) +------+/ +------------+/ \+------------+ \+------+ |Host A|------|(2)SGW A(3a)|===Internet===|(5a)SGW B(6)|-------|HOST B| +------+ /+------------+ // +------------+\ +------+ (9) // (10) (4) // +----------------+/ // |IPsec HOST C(4a)|=======// +----------------+ Hmm.. probably not. I think it is simply better to explain that in the text saying that (2) and (6) only cover the traffic destinoned to the tunnel, not the traffic destioned to the SGWs themselves. > >> B. The following text will be added to Security Considerations: > >> > >> An IPsec implementation is configured to pass ICMP error packets over > >> SAs based on the ICMP header values, without checking the header info > >> from the ICMP packet payload. > > > >I think that needs some kind of rewording like "An IPsec > >implementation can be configured ..." or similar. > > I should have said: "if an IPsec implementation is configured to pass ..." What happens if it is configured that way? It does not tell that either... Perhaps it should say: ---------------------------------------------------------------------- If an IPsec implementation is configure to pass ICMP error packets over SAs based on the ICMP header values, without checking the header infor from the ICMP packet payload, then the attackers can cause DoS attacks by sending the ICMP packets through the SGW to the other end, just like they could if the hosts would be on the same network. ---------------------------------------------------------------------- > >> For example, a tunnel may be created between two sites that uses ANY > >> for protocol and port fields and IP address ranges that encompass > >> all systems behind the security gateways serving each site. In such > >> cases, the hosts behind the security gateways will be vulnerable to > >> DoS attacks that might be launched by other peers with which there > >> are active SAs. > > > >Perhaps we should describe the situation more here? > suggestions? Hmmm.. not really, but remembering the items raised in the IESG to the UDP encapsulation draft, they always wanted to see the real attacks, not just text saying there are some attacks. Perhaps it is just enough to say that the attacker can do all same attacks with ICMP messages, it could if it would be on the same network (including faking the header and contained payload IP addresses). > >BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF > >processing stuff from there (section 6 and appendix B)? > Yes, Karen has not yet added back the PMTU text. After we have this ICMP and that PMTU text done, we should be ready... I do not know anything else missing... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 12 17:44:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10346 for ; Thu, 12 Aug 2004 17:44:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvNIQ-0006g4-LH; Thu, 12 Aug 2004 17:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvNEJ-0005a3-Tn for ipsec@megatron.ietf.org; Thu, 12 Aug 2004 17:35:23 -0400 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 RAA09800 for ; Thu, 12 Aug 2004 17:35:21 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvNJJ-0007Ht-Bx for ipsec@ietf.org; Thu, 12 Aug 2004 17:40:36 -0400 Received: from unknown (HELO exch01.corp.netscreen.com) (10.100.3.55) by kremlin.juniper.net with ESMTP; 12 Aug 2004 14:34:49 -0700 X-BrightmailFiltered: true X-Ironport-AV: i="3.83,98,1089010800"; d="scan'217,208"; a="2704296:sNHT32145792" Received: from exch06.corp.netscreen.com ([10.100.3.109]) by exch01.corp.netscreen.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 14:34:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Aug 2004 14:34:46 -0700 Message-ID: <19D9FC12B7479045965A9D0297B866226B834E@exch06.corp.netscreen.com> Thread-Topic: comment on "empty message" in IKEv2 draft Thread-Index: AcSAtENoNK3PnmHIT26eaMzASWrVwA== From: "Yonghui Cheng" To: X-OriginalArrivalTime: 12 Aug 2004 21:34:49.0013 (UTC) FILETIME=[31BC9E50:01C480B4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Ipsec] comment on "empty message" in IKEv2 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: , Content-Type: multipart/mixed; boundary="===============0293960732==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0293960732== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C480B4.302A7193" This is a multi-part message in MIME format. ------_=_NextPart_001_01C480B4.302A7193 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All, =20 The IKEv2 draft/RFC should emphasis that when send "empty" messages in IKEv2, the actual messages should include an empty "encrypted payload". =20 "Empty" messages is used for DPD (dead peer detection) and acknowledge purposes. Without encrypted payload, the message is not authenticated, which should considered as security problem. =20 Yonghui =20 ------_=_NextPart_001_01C480B4.302A7193 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All,

 

The IKEv2 draft/RFC should emphasis that when send = “empty” messages

in IKEv2, the actual messages should include an empty = “encrypted payload”.

 

“Empty” messages is used for DPD (dead = peer detection) and acknowledge

purposes. Without encrypted payload, the message is = not authenticated,

which should considered as security = problem.

 

Yonghui

 

------_=_NextPart_001_01C480B4.302A7193-- --===============0293960732== 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 --===============0293960732==-- From ipsec-bounces@ietf.org Thu Aug 12 22:10:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24532 for ; Thu, 12 Aug 2004 22:10:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvRUQ-0005wL-Pq; Thu, 12 Aug 2004 22:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvRTa-0005f7-6b for ipsec@megatron.ietf.org; Thu, 12 Aug 2004 22:07:26 -0400 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 WAA24302 for ; Thu, 12 Aug 2004 22:07:24 -0400 (EDT) Received: from web90007.mail.scd.yahoo.com ([66.218.94.65]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BvRYd-0003Pk-W0 for ipsec@ietf.org; Thu, 12 Aug 2004 22:12:41 -0400 Message-ID: <20040813020653.97552.qmail@web90007.mail.scd.yahoo.com> Received: from [210.210.122.197] by web90007.mail.scd.yahoo.com via HTTP; Thu, 12 Aug 2004 19:06:53 PDT Date: Thu, 12 Aug 2004 19:06:53 -0700 (PDT) From: Network Guru To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ipsec] world class 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="===============0807649510==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0807649510== Content-Type: multipart/alternative; boundary="0-1794566816-1092362813=:91030" --0-1794566816-1092362813=:91030 Content-Type: text/plain; charset=us-ascii I have the responsibility of buidling a great network team for international /domestic projects and I am looking for quality networking guys to work for me. If you are based out of India or in the US / U.K , please do get in touch with me offline Regards, --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! --0-1794566816-1092362813=:91030 Content-Type: text/html; charset=us-ascii

I have the responsibility of buidling a great network team for international /domestic projects and I am looking for quality networking guys to work for me. If you are based out of India or in the US / U.K , please do get in touch with me offline

Regards,

 

Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage! --0-1794566816-1092362813=:91030-- --===============0807649510== 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 --===============0807649510==-- From ipsec-bounces@ietf.org Fri Aug 13 04:37:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27526 for ; Fri, 13 Aug 2004 04:37:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvXVn-0003uo-Pb; Fri, 13 Aug 2004 04:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvXVd-0003mk-QQ for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 04:33:57 -0400 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 EAA27462 for ; Fri, 13 Aug 2004 04:33:55 -0400 (EDT) Received: from web8205.mail.in.yahoo.com ([203.199.70.126]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BvXac-0001HQ-Sj for ipsec@ietf.org; Fri, 13 Aug 2004 04:39:16 -0400 Message-ID: <20040813083315.24549.qmail@web8205.mail.in.yahoo.com> Received: from [203.128.1.251] by web8205.mail.in.yahoo.com via HTTP; Fri, 13 Aug 2004 09:33:15 BST Date: Fri, 13 Aug 2004 09:33:15 +0100 (BST) From: =?iso-8859-1?q?khan=20wadood?= To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit Subject: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA and first CHILD_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 Content-Transfer-Encoding: 8bit hi, How may proposals Initiator will send in the first xchange i.e., IKE_SA_INIT. If Initiator wants to make two SAs i.e., IKE_SA and first CHILD_SA(piggybacked with IKE_SA) having same cryptographic suite. Or we can say A single proposal for IKE_SA is sufficed for first CHILD_SA. If CHILD_SA uses the same cryptographic suite as of IKE_SA. Any comments/answers will be highly appreciated. wadood ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 13 06:17:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03283 for ; Fri, 13 Aug 2004 06:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvZ36-0002rz-9o; Fri, 13 Aug 2004 06:12:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvYz4-0001gI-Pm for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 06:08:26 -0400 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 GAA02646 for ; Fri, 13 Aug 2004 06:08:24 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvZ4D-0002uk-Ow for ipsec@ietf.org; Fri, 13 Aug 2004 06:13:46 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7DA8HYu006461 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Aug 2004 13:08:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7DA8HSb006458; Fri, 13 Aug 2004 13:08:17 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16668.37649.462812.11513@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 13:08:17 +0300 From: Tero Kivinen To: "Yonghui Cheng" Subject: [Ipsec] comment on "empty message" in IKEv2 draft In-Reply-To: <19D9FC12B7479045965A9D0297B866226B834E@exch06.corp.netscreen.com> References: <19D9FC12B7479045965A9D0297B866226B834E@exch06.corp.netscreen.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Yonghui Cheng writes: > The IKEv2 draft/RFC should emphasis that when send "empty" messages > in IKEv2, the actual messages should include an empty "encrypted > payload". True. > "Empty" messages is used for DPD (dead peer detection) and acknowledge > purposes. Without encrypted payload, the message is not authenticated, > which should considered as security problem. Note, that empty messages can be used for dead peer detection, but they cannot be used to proof liveness. I.e the malicious peer can create responses to empty DPD messages before hand and give them forward to somebody using them to claim the other end that he is not dead even when he might have already been gone. This makes for example DPD done after the NAT-T not so secure as it could be. I.e. malicious initiator can use NAT-T to do 3rd party bombing against 3rd party, and continue doing that even when the server tries to do return routability checks. There would be easy fix for that, simply server includes the N(COOKIE) notify payload inside encrypted payload in the DPD, and then we simply add text to the draft-ietf-ipsec-ike2 draft saying inside the "COOKIE 16390" section saying: If this notification mesasge is received in any request, it MUST be included in the reply packet, with the exactly same data. This would allow the servers to decide which kind of return routability checks (if any) they will do with NAT-T. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 13 06:21:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03591 for ; Fri, 13 Aug 2004 06:21:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvZ6C-00045A-Jl; Fri, 13 Aug 2004 06:15:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvZ2O-0002P6-H4 for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 06:11:52 -0400 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 GAA02878 for ; Fri, 13 Aug 2004 06:11:49 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvZ7X-0002yl-Eg for ipsec@ietf.org; Fri, 13 Aug 2004 06:17:12 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7DABoYu006522 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Aug 2004 13:11:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7DABn10006515; Fri, 13 Aug 2004 13:11:49 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16668.37861.836089.18489@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 13:11:49 +0300 From: Tero Kivinen To: khan wadood Subject: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA and first CHILD_SA ?? In-Reply-To: <20040813083315.24549.qmail@web8205.mail.in.yahoo.com> References: <20040813083315.24549.qmail@web8205.mail.in.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 khan wadood writes: > How may proposals Initiator will send in the first > xchange i.e., IKE_SA_INIT. If Initiator wants to make > two SAs i.e., IKE_SA and first CHILD_SA(piggybacked > with IKE_SA) having same cryptographic suite. Depends on the policy. The CHILD_SA parameters does not affect to that, as CHILD_SA proposals are sent inside the another SA payload inside the IKE_AUTH exchange (SAi2, SAr2). SAi1, and SAr1 are only used for IKE_SA, and the SAi1 can have multiple proposals, if those are acceptable, and SAr1 will always have one selected proposal. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 13 07:46:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08196 for ; Fri, 13 Aug 2004 07:46:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvaRK-0003x4-DJ; Fri, 13 Aug 2004 07:41:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvaJN-000898-L3 for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 07:33:29 -0400 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 HAA07254 for ; Fri, 13 Aug 2004 07:33:28 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvaOU-0004Kq-Ce for ipsec@ietf.org; Fri, 13 Aug 2004 07:38:49 -0400 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 i7DBWoD32075; Fri, 13 Aug 2004 13:32:50 +0200 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 i7DBWoSj069584; Fri, 13 Aug 2004 13:32:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408131132.i7DBWoSj069584@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Ipsec] comment on "empty message" in IKEv2 draft In-reply-to: Your message of Fri, 13 Aug 2004 13:08:17 +0300. <16668.37649.462812.11513@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 13:32:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Yonghui Cheng , 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: There would be easy fix for that, simply server includes the N(COOKIE) notify payload inside encrypted payload in the DPD, and then we simply add text to the draft-ietf-ipsec-ike2 draft saying inside the "COOKIE 16390" section saying: If this notification mesasge is received in any request, it MUST be included in the reply packet, with the exactly same data. => A nonce payload should have the same result, quoting the IKEv2 draft: The Nonce Payload ... contains random data used to guarantee liveness during an exchange and protect against replay attacks. I don't know what is better, COOKIE notifications or nonces. The only visible difference is the length (1-64 for cookies, 16-256 for nonces) but this is not enough to choose. Same about the stateless property of cookies, here we have an IKE SA so already some state... What do readers of this mailing-list prefer? In any case we'll get this mechanism in MOBIKE. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 13 10:42:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19789 for ; Fri, 13 Aug 2004 10:42:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvd96-0003LK-01; Fri, 13 Aug 2004 10:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bvd5y-0002u3-2A for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 10:31:50 -0400 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 KAA19242 for ; Fri, 13 Aug 2004 10:31:47 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvdB8-0007gm-Kb for ipsec@ietf.org; Fri, 13 Aug 2004 10:37:11 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7DES9g22467 for ; Fri, 13 Aug 2004 10:28:09 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7DESwJO001870 for ; Fri, 13 Aug 2004 10:28:58 -0400 (EDT) Received: from rndf-157-130.telkomadsl.co.za(165.165.157.130) by nutshell.tislabs.com via csmap (V6.0) id srcAAAuAaaNd; Fri, 13 Aug 04 10:28:50 -0400 Date: Fri, 13 Aug 2004 07:34:18 -0800 To: ipsec@lists.tislabs.com From: annie@tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------aicuxuixlajbvyskwfnm" X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Subject: [Ipsec] Hey! 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 ----------aicuxuixlajbvyskwfnm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ipsec,


I'm so bored, let me talk with you...

Further details are in attach.

Cheers, Annie
----------aicuxuixlajbvyskwfnm Content-Type: image/jpeg; name="myphoto7.jpeg" Content-Disposition: attachment; filename="myphoto7.jpeg" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAAQABAAD/4QDmRXhpZgAASUkqAAgAAAAFABIBAwABAAAAAQAAADEB AgAcAAAASgAAADIBAgAUAAAAZgAAABMCAwABAAAAAQAAAGmHBAABAAAAegAAAAAAAABBQ0Qg U3lzdGVtcyBEaWdpdGFsIEltYWdpbmcAMjAwNDowNDoyMyAwNTowODowNwAFAACQBwAEAAAA MDIxMJCSAgAEAAAAMjU3AAKgBAABAAAAiwAAAAOgBAABAAAAoAAAAAWgBAABAAAAvAAAAAAA AAACAAEAAgAEAAAAUjk4AAIABwAEAAAAMDEwMAAAAAAAAAAA/8AAEQgAoACLAwEiAAIRAQMR Af/bAIQACAUGBwYFCAcGBwkICAkMFA0MCwsMGBESDhQdGR4eHBkcGyAkLicgIisiGxwoNigr LzEzNDMfJjg8ODI8LjIzMQEMDQ0SDxIjExMjSjEqMUpKSkpKSkpKSkpKSkpKSkpKSkpKSkpK SkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpK/8QAiQAAAgIDAQEAAAAAAAAAAAAABQYEBwID CAEAEAACAQMCBAQEAwcDBAMAAAABAgMABBEFIQYSMUETIlFhBzJxgRSRoRUjQlKx0fDB4fEk M0NiFnKyAQADAQEBAAAAAAAAAAAAAAABAgMABAURAAMBAAIDAQEBAAAAAAAAAAABEQIhMQMS UUEiMv/aAAwDAQACEQMRAD8Aoto+UZG6E7V9EPMFJ+jelSBCYz4ZdXUjrnGPzFYSQlNnBxnG Rvk0tLT9MiuR4b4DDoR0rCRNzHLhZF6EnrWtvFb5jycvc7Gt9taQXAJa7RSOpkPKKMA9oig4 PXeiWmzBlMUhGT0J/p96HzqiSFI2jYD+Jc1nabPkSoCAcBhkNt0+tbWajZ1GGpbaO4i/Cy4H NtE/8jeh9qDmOSzm2UCWLZgDn71Pg1iPlUXER5wQCw7+9TL62F3CJYN5ohkFf4l9P7VJN5cZ TSW1UXH8DPiELhY9E1iY85XFvKx2PouauwVxLpc8mmXkVwc+HkHKEjlPZh+v5EGuofhjxj+2 bKPT9RkQ30SDw5Fzy3CY2YZ61a/hyvM5Q9dq8IIGa9JFe5HLRAY9d81GuoQQWA2PUVvbIPKA OU9a8jIZBgEA9jsawrV4A06cmSc4FQ3mjjOJAVXOz4zRi4iUknzBQcb9qHyRAIUK+Xuu++ad EGoQJleOYMXPhORnc+Woc18FlZXj8Rgfm8Itn7gb0RkiMKDwfl7A9DmhE1hN4rct9Kqk5A/d jA9N1zRFOYyXKASczLjIDE0NeZhNzx+XHy+1HLiH93ld+VSSTsT1pdrn8fJ6nl/DZHyPJ++Z 8HuOtFYtLi8LxG5So+ZuYhR+VC7WF57hI4yAzHYk4q17fhoycM+DcKIiF5ldTgk+v1p20iMb 6KomSNJHVH5gD5SpyDWsMV6EinbTfhXxPqTlobPwoCdpZTgEew6mn/hv4IW9qizaxOLqY/8A jGyD6e/1oPaGWGVx8L+G9O4q4gmsdWkukXwS8bwEDz5HU4PYmjHGXAOqcBzC5mxd6XLJyJdo Mcuegcdj+n9KtbRuCIOGr83OnW45G2demRTXxRbW2v8ACGqWV4AkUtqytzEAKQMhs+xwftU2 6Plepy/JFbXCtPBNC/KMypzdcnrj8s49M74NMHAGsC21e1sJrkW7MQ1pdk4MbHop+vT070iX ls1lqfg278zoV5XRuYEkZyD3B7UZuLqK3dZJYIJbpuUtGvlRWA6/X1o9JC/6rOuOGdZ/adu0 N2oh1G28lzD6H+YeqnqD70aIBH19K5z4O441l5rW4mQC4tk5UOMGVP5WOPMO2e2KvbhjX7Pi PSUvbJuhKSxn5onHVT/m9OtJk3l57CZGBg/nWBOF2H2rYyll9K1LGVbr/amEZ8QHXBBP1oZe RGIsWwR2otjBrXPEssZRuhopiazULzIZIP3g5d8Ag747GoBWUEgtNnJzyrt/WixQQSPbleUK c9NsVqPIDg832xTkDlWeYLC42K8nftQTSNLu9YvVtLCPnlb1OAB6mmK6tfEg8PBaQjZF3P3P ajXwbkXT+IZ0uVVWZRyh+4rk8b4cPV8q6CvCnwkuklhnvbhufIysQxj71dHDvB9pZRpzR7Dc c5LE/UmimmRwtAhUDDDIGNqJxqMDI+lHt1i2KI1PaorCGLl52XuNlHqaFNqenQaqmnLdJcXj bmNTuB3Jx0rHX59QtNJ1CWAk3c+RGR/416DH6mlrgDhWHStUvLqC5uLxJXDLJOvK2cYJPqfe s4BX9Huez5oTgde1AdXsVubOaCZB4TjlcA42NNwHkGfSoklrGzEFQc0WgLX05P13hSXhviwR Hmn06ZmdC+42BIDfSh6WCXWpF7cMEyCzv6mrh+LFm1vdwW0aKqS5OSNsZpCsrZAxJGOXbf8A TP8Am1R3vktjKgR0u3ZII0kc7Hm8vcYpt4Ku5NE1g6haNmOYCO7hIwJVHRvZx69xtShPex6d BzTMpjQHAY9cUAuPiRLChWziznPmJxQ8ftajeT1kZ1hYX9tqEHi2kyyKeuOo+o7Vurm3hbif iLUntX01pIrmbHIYsc3fYjoR9ulXJo+v6xZwwxcR/s+5lZiviWUmGGO5Q7fkftXUn9OXUQ3V 8a121zDdwJPbuHjcZDCtlMIaLq3WZMMu4GxoBNbASsGiBIPcZpmNayqk5Kg/amTJ6zTlK2j8 J0GzO42J39Nv+a03+lzwyJe2L+HNGQQR/CfSp8QHIyqAXO5Zu9TdPR/EHOD4bEczHIyDt/av OTafB6zV7G7gD4iwxxG11dvAmhXLK/p/MvqKdm+IOmiza7lingtgcJLOvhiQ+wO9UnrWmR2m oQmMhXGJo3XqrZ7Z2ohJdahrmvQRXJtrm2EDIyTrzIScZyOx22Iq60rGc7y5UXjw7xPZcRQx +GGSR08ROYbOvqP7dRRrkS3HlQDvgClDh7QltbCGNOWHwVAj8Pbk+lHLjXYorVorkMLv5AAp wx9QfSmorRPMs5jL+KqAAk5HQVo0a/e/iklZCAsjIDn5sd/vQ+3v47sSRlla2tgBMy9Gf+Ue oz+tEdA5BasUIYPISDjGffFYzUQmfF22LJaSjA+YHb2H9qrC58OJGdBh99sbVbHxeKHTrRCM lpCMfaqK4tv2tLZwH85HKN9/bNQ2rqFsP+aK/E2rvez+AjfukO/1qPw3oN7xDqdvY2KjnmkC AscDJoX1bcner2+Emi2tkj8UahCsdlZxjw1x/wByXGNvXt9zXWksqHNpvToetbbSOC7FtG4c RLnU5YzHNenpFkbgehz/AL0p3NndRTh5nORsWLEmpmpaj/1ck5UK905l5RvgZ2Fb7e7+aV40 kLb4YbA1JsZZI+i69rGm3C/s+7eCL+JT0P2p40z4nNFIkOpxLKejPGvKfy6Un3EiyJJK0cYL 4IUbd/8Amh4ty2CBudvpWWmgvKZf2n6na6narc2MySxkZODuv1HY1IVgwBU5BqjdH1W80S6/ E2k/K6jDxno49CO9Ptlx/p81rHJNdJDIw80fJ8vt1q2XTn2nllLxWrBsyAYBxv0ovZRhZwJ0 Cq2wOR5OuRTBHogvtIhDQkTjOeQeY42xg0Q4Z4J/FK9xcKzJnPg55XRveuXPjaOzXkTA9xwl cX1iGgVpWVuZD029M43G/wB6hcP6HdTzyWdvG4aNiWTADfXfrv8AlV16Hphs7RYw5C4xykdP ShnEGj/hJH1LT7USXIGVIzkN3OB1zsKo/Gu2SXkfSAmj3OpWts6wR+PJEMLA7YaT6HsfY96X Lv4iaBJdGDia3v8ATJAf+3PCUI+hG361aNpax3MC3Nxb+DcSqOdc759c0mcQQm8mk024CPNG SUMgB5x6Y6d8YrPgZOiinF/CdveLFpOtvFbc3nidXx133OcVZGgcQaW+nrJbX1q0Krkusq8q j39K5a470STh7ia5jjVhbSuZYG9VJ6fY7Vlw3Fa3xkS6gSRTjZmI29AR60WllVBT9uGWzxxx vb8SazEumuZbO0cqsn8MhHzEeo7ZqrePbpWnjhjJw3nNM9vptjZWsRtZzFttG3m5c79etJHE ml366hcTPEXj+YMhyAKniPdG1xiEXStHnvreS7AAghkRHycE59KvP8ZZW3w50fQ/HD6gxE7R IclV7E/pVKcPyuHS3n8Vbd3yGVSQG9aszUrWCDUnOixMbTw42eVUIHNjByftV9M50jC9kjXU 7VX2UKepxjepKOqTeGScHoO1CtQbFxExYBy2Pbt0rdcXHLcIM5wMZNTZRB2NBJ5Rk4UffNZW 6BZjzt1yMAda1adKz82Tk4XO1SLjIUN0PTIpBgfKSl2HkbmHNkEelSGsIXPMi5U9O1RpxuME knbPpUJrmZWIWTIHrimAy5uEdM25bxhIcdznf/T3pqitIop2kjXlL/Njv71H03TYrRjIBiR/ mwdqI1eEOzzl9Nqwij8NeUsW9yd62VGu5GjHMozyeY+49vesEwv5VjgZucDFVtq11LFxNFdM 2SeYFyOo6Y9dqY9cv+exbw2YsRkgfMvsf6flVV/Em+uLHh2V0blaR/CQnqpYHP8ASp7V4KeN zkrrj/ieLXdUuYwnPbROVt3HU77t96y4E0qWeVmlHIoGwOd/+KU5N0Rtj2qwuG9Qij06CVMG UoFcKceuPvW2pmIOHzWMQ0r8JEH5QJCRluuR2/qK1R6Tb3CssnmGc4YA0I1XiNHXyvyKRh9i PNj1oa/Ed14LQab5pAMtMw2Uf8Yrn9Wzoo2i0tLHlEUI9wKK2B5o0WJmBPyhQW3+n50qaU8k Wmi7vZCN8hW+n+1NlgbnQeHZddv/AN3qN6PBsI2GCqk/OR2OPyAo4xWLvUQB4mtjZNujrySD PMvKVJGSMH6UMv5AlvDJkHP+daL8UXk9/ZTzuS4REYM/VsHGf1oA0n4vTcoykgk49BV0jnbG PhiQyibB2wp9T3o5NCXQtjlB6UjcI3jJfyW5wS8ZUKe+9PU8nOiLjcL09/8ABSaUY+XUBbrH icvLtnoK0G3Uknk/WpEyhps9x2qagiCgHmJHpWMdALkDfr617UW0uPFjMjNt1wVwR9a+N7Er YJ2xnNXIU3scHOdu9CtUuEnheInlXYgn1ry+1OIeKhcKyAEZPWlnWNXHhk5Un/8AQxWB2Cby /aJJYicqSeu+/wBaQOP5xf6BNDGhkZGSXHuvUflTHql7zszKM9du/wB6TdYuG86KRGh3dj0A 71HTjpfCvBWfhF1dEA+fK59K32GoS2jNHIMovlwe2/Ss1YR38kYGIi+xG23Y71LaON5B4wfw ZCPEEfzFQd8Z796tfok+BSwaDVrEu6qsgOG82ATv2o/wdw7ea1eyQWECR2qACe4cHkiHoT3P tSvyw6nxDb2fD1u8OmvLGP3gy3zAFmrqPhPTLc23KskJt4ZOVIoE5EYjufWpvKo624LMGhWm kPYx2+nQXFxOxEL3G7MAN25egGelQviNwrPDobaveaiZrxHUMjACIKxAKqP8zVnvaWp1Fbtw rTRIVQn+AHrj60H4otLLVNJlm1SNXs41LIHOAoAOX+vpW6B2UOkcraLFHI/iFrQr5uuwyP0F BdLA/CyI+ct0B9KZYJIibXwivIBjp/Cf9qWwjQzmNt8Er+uKyYNIGaZdfguJLV2xtIAd8bGr LmlPNnoR0ANVhq8BN7zKPK3fG43p84evxfaV4jsDNCQj5Hf1+4o7+mx8JxgLShvmOM5zWDmP nOVNSZZUWA+CwKmhrXgU4blJ9xUihch1yF8mCfwnJ23GGPv71rl1JW8QSkRgHA67VRl7HqOm 6pDaXM0yrIeVXS9/dhvdmTbPv6ivNU1G40yVF1C+1KHJwDFNFPg523KgfXerezI+iLbv76CT Ds/MG7HIIodqPgSwlo3QsNwgNVfqXEsmnMhe91pVlGMyxW+5zv0Ppg1Dm4lNsgaa91BebPKW to2z+T0G2FZQ3andxW7M88jICfkIJ5j2Cjvk9qQ+Kb2V5CpXwwpwY18wVv8A2PQsBny9B3rK fV4ILmCWZrlmmysly6BTEpHSMZbB/wDbrvsKXrnFvcmMyEwcx5Tktj/P1pZ9KqHl54dvKOWY ypMgdXOebfrn71OtZI7izCqQWTf6+oofPaSm2NxKTHCu6lurk+n1qRpXPMyQwRFmB5hgbn2x T/gj4ZL4Mkf/AOY2cKkqj3ABXONs5wfyrrPQE/C6aioADnO1c58B8MQxcV2kr3f/AFKTZ8Dl 6Ag9/UV0rp8YWCPA7Z2oPlmXC5JMeLheTbOcsfWh/EUKT2b21wM2/IecHo22wqacRLlWHMTS 18ROIrTTuHJEZv8Aq5iscI78xIAoGKS01UCQxxHKQ88YwfRmFa7yIftGYkkCTfm9Mj+9RuDp U8a5s5CxkV2dS4ORvvn70Q15Sj28oIUB+Q479x/rQajhrVQLf2POx5W52j3PL+u9R9N1X9m3 I5iVUnDrn5gf7Ux6jbgW6TwtnOFKgDOcZ3pS1KyVn8SNslh5m7D70657E66HS2v0kgIHynoR 3rSZcEh1Yt32/wBqFcLzhdOVZPO0TFQ2cZHUfoaMfiv5YyQd+tTajKJ1AK11Z7mCTh/XGY8u 0MrnJ9vq2O57VBuL5hay6ZqAE7McRTknoOn39+/Q1rvp49ftA5KxXkQ8wA6n1B96EyXJuYvw 927eNFkIcfp7UU6F5JMF34kf7L1BzJESBG/NgDrjr6dvyrCKZRHJpt03Mi58CXGOlC5XaTaQ 7jbPrXxlaYBZCSw2U9z6fenaoq4ZsuvEgU20pblIDA+1ENP0qSOOK61AELjnigPVvQt6Dv8A 4Kxs7d5PDur3eOEZAOw+9FUkS4DXGoKwhOyQg7yY/m9B/m/Sl03Bs5VB2qT3OqQTTthYU79A SOw/z/StfCGrnTdZtvECmCRhHJkfwnbP260QvYHmsfxd24toQP3EQT5/p6ffr1pXdPM5xgDJ xRxyobydl7/D/Ry3GN9cXSESwokcfMMZBzk/oBVwwTtEmAQSNt+9Ul8OOMLa9t7WK8lEWq20 fKjE+W5T0z/MNtqtrSNYhv4yEkVXUZKk7j1pZAWkXi7iqy4dsXutRmEajYKerHsAO5qhPiHx Pca5eRTytywx+aKE7hSD1OOvbevfjBqlxrXEDzXE2LVFItU7AA4J9yaH6dpMWraLBOJ1RuQh zgk5DY6fQj8xVM9k99H2uTXEet/tSBiiXKJJzA7/ACjI6df70wPfrqOjuwwsiqHwp7juP12p d1iD8PGlsFUeDKOUqd/Ku4367YI+4qbo1/AEmLeFyFcg4wW29PX+9NrNJ51A1pd8JbCS2Eal JfMZA2eZsdzQaZVs7liHU5xuBuGG49qw0qUwWk4KFIwQVPRgD2P0rDUpJoEEyKkkQBILDOx/ zvUumW7RjpqS6ZdSRllkhuHzgjC53JxU99ft4mMeVPLt1FKt/dtdAOqNHGfMm52I9P7UZi0C 3uIkm/ESjxFDbDI3FM19AuBduJgkwu7VuTJ+X+ua03bi6AmQcsi+nWo/NytzdfWvA/I2Y9s1 oUv09eUSAM5ww2O1brNY4cXE5zj5UHc/6VGU8vmbqa2IMuGl2HbNFirsKxyPcH8Vd+WEHyJ2 OP8AOtS47q25nutQyzAgpENgcdM+31+pz0IQzndmJxtgd6yilSNxcSqsrA+WNvl+p/t3pYMH LwS3UX7T1uQhJMiC3BIZh2Psvv1P60v3V0JYIownKVyWPqazurua6kklvJJHdlypJ6nt17fS oTEs3N1J9BTZQmtUnWzrFGuMvNsyebCx+h2706cO/Ee4t7U2msW8d8ApXnL+HIR/9u+3rSCC d2G1eYDeY4/OtDFh6nqPCvE5jiuLi60mVNo2lQPF+Y+1RuH7S/0S4msbuRJtNuFJS4gcOoPT II6bZzSOHIJwFGdsAUY0q9uYbc28pdLS4mjWQjbAyd84+lFRC6TaCetrJHHHeQSfundo4wI8 BOU7fXPmobZzgQATMD4WV5QM5Xt/WmLXZ3NpPDMkcrBudRjYqDkDbvufzpcdzLMDDzF1XkaE 7ED096oRCunzsp8IYOxwzEYYkZGe/bpRVpLWSwiNrFzRsMMrHf3+lLhgmi5GhikMuQ+Mb/b1 9fpUg6lKlzJPgfh3RS6sCpGdth3qe83kphzgx1PTuW3R4biIhieWJvT2rTHeXtqgghu3jjTZ V64rVf30X45GiZzbqCCyjG9SoXtzEp5lbbqWFIVh/9k= ----------aicuxuixlajbvyskwfnm Content-Type: text/html; name="Details.exe.htm" Content-Disposition: attachment; filename="Details.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Details.exe
Virus name: W32/Bagle.z@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------aicuxuixlajbvyskwfnm 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 ----------aicuxuixlajbvyskwfnm-- From ipsec-bounces@ietf.org Fri Aug 13 11:03:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21357 for ; Fri, 13 Aug 2004 11:03:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvdJm-0004sE-9n; Fri, 13 Aug 2004 10:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvdCw-0003kl-BC for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 10:39:02 -0400 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 KAA19697 for ; Fri, 13 Aug 2004 10:39:00 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvdI7-0007mi-2J for ipsec@ietf.org; Fri, 13 Aug 2004 10:44:24 -0400 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 i7DEcQjh003677; Fri, 13 Aug 2004 10:38:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <1092256900.411a84840e4e7@webmail.nist.gov> References: <1092256900.411a84840e4e7@webmail.nist.gov> Date: Fri, 13 Aug 2004 09:21:50 -0400 To: Sheila Frankel From: Stephen Kent Subject: Re: [Ipsec] Paddding Issue in AES-XCBC-MAC-96 with IPSEC (RFC 3566) 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipsec@ietf.org, howard.c.herbert@intel.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 At 4:41 PM -0400 8/11/04, Sheila Frankel wrote: >Actually, I came to the opposite conclusion: > >This question is addressed in the AES-XCBC-MAC RFC; unfortunately, it appears >in a different section than the algorithm definition. The AH RFC, in section >3.3.3.2.2, exempts MD5 and SHA-1 from the implicit packet padding >requirements, >since they have their own padding conventions. AES-XCBC-MAC was not defined >when the AH RFC was written, but it is treated in the same way. Thus, the >padding will be performed according to the AES-XCBC-MAC specification, and >Case2 will occur when the packetsize is not a multiple of 128 bits. In fact, >the AES-XCBC-MAC RFC, in section 4.2, states "with regard to 'implicit packet >padding' as defined in [AH], no implicit padding is required." > >Sheila Frankel >sheila.frankel@nist.gov > Sheila, Good point. As you note, we make an explicit exception for MD5 and SHA-1 in AH, both the RFC and the new I-D that will replace it. Maybe we should remove these references to specific algorithms in AH and ESP and, instead, refer folks to the documents that define how to use specific integrity algorithms with AH and ESP, re padding. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 13 11:05:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21484 for ; Fri, 13 Aug 2004 11:05:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvdMj-0005aB-CR; Fri, 13 Aug 2004 10:49:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvdDL-0003lA-6u for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 10:39:27 -0400 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 KAA19704 for ; Fri, 13 Aug 2004 10:39:24 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvdIW-0007nA-Ei for ipsec@ietf.org; Fri, 13 Aug 2004 10:44:48 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7DEZlg23335 for ; Fri, 13 Aug 2004 10:35:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7DEaZGv002698 for ; Fri, 13 Aug 2004 10:36:35 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7Baarf; Fri, 13 Aug 04 10:36:33 -0400 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 i7DEcQjp003677; Fri, 13 Aug 2004 10:39:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16667.12455.633747.116620@fireball.kivinen.iki.fi> References: <16664.44629.116209.965728@fireball.kivinen.iki.fi> <16667.12455.633747.116620@fireball.kivinen.iki.fi> Date: Fri, 13 Aug 2004 09:51:18 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: [Ipsec] new ICMP text for 2401bis 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipsec@lists.tislabs.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 Tero, Yes, diagrams to explain which ICMP flows we're talking about are tricky to construct. We'll give it a shot, but a table to eplain the flows will be needed. >What happens if it is configured that way? It does not tell that >either... Perhaps it should say: > >---------------------------------------------------------------------- >If an IPsec implementation is configure to pass ICMP error packets >over SAs based on the ICMP header values, without checking the header >infor from the ICMP packet payload, then the attackers can cause DoS >attacks by sending the ICMP packets through the SGW to the other end, >just like they could if the hosts would be on the same network. >---------------------------------------------------------------------- Yes, we can include text along these lines in the security considerations section to explain the dangers of configuring SAs that allow transmission of ICMP error messages to skip checking the payload. > >> >> For example, a tunnel may be created between two sites that uses ANY >> >> for protocol and port fields and IP address ranges that encompass >> >> all systems behind the security gateways serving each site. In such >> >> cases, the hosts behind the security gateways will be vulnerable to >> >> DoS attacks that might be launched by other peers with which there >> >> are active SAs. >> > >> >Perhaps we should describe the situation more here? >> suggestions? > >Hmmm.. not really, but remembering the items raised in the IESG to the >UDP encapsulation draft, they always wanted to see the real attacks, >not just text saying there are some attacks. OK, we can add an "e.g.," and give examples of the sorts of DoS attacks that can result. >Perhaps it is just enough to say that the attacker can do all same >attacks with ICMP messages, it could if it would be on the same >network (including faking the header and contained payload IP >addresses). > >> >BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF >> >processing stuff from there (section 6 and appendix B)? >> Yes, Karen has not yet added back the PMTU text. > >After we have this ICMP and that PMTU text done, we should be ready... >I do not know anything else missing... Always nice to hear "we're almost done" feedback :-) Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 13 11:49:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24147 for ; Fri, 13 Aug 2004 11:49:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BveAJ-00064I-2p; Fri, 13 Aug 2004 11:40:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bve6Y-0005D7-VB for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 11:36:31 -0400 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 LAA23256 for ; Fri, 13 Aug 2004 11:36:28 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BveBj-0000a6-Jc for ipsec@ietf.org; Fri, 13 Aug 2004 11:41:53 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7DFWlg01330 for ; Fri, 13 Aug 2004 11:32:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7DFXb83010802 for ; Fri, 13 Aug 2004 11:33:37 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAAwYa4ev; Fri, 13 Aug 04 11:33:35 -0400 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 i7DFaBjl006968; Fri, 13 Aug 2004 11:36:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200408072032.i77KW0MP014288@rs15.luxsci.com> References: <200408072032.i77KW0MP014288@rs15.luxsci.com> Date: Fri, 13 Aug 2004 11:35:20 -0400 To: "William Dixon" From: Stephen Kent Subject: RE: [Ipsec] OCSP in 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: 25620135586de10c627e3628c432b04a Cc: ipsec@lists.tislabs.com, "'Michael Myers'" 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 1:30 PM -0700 8/7/04, William Dixon wrote: >Hi Mike, please correct my understanding here if I'm making a mistake. You >mentioned peer-to-peer applicability which prompted my investigation. The >summary is that your draft should be more clear about the risks of using >OCSP inband with IKEv2 in peer-to-peer scenarios, such as not recommend it. > >I think using OCSP inband in IKEv2 for peer-to-peer would not be recommended >- as it is limited by the classic problem of how an IKE initiator knows >which credential or trust anchor to expect from the responder. There are >deployment scenarios where this situation is solvable - such as IKE >negotiation to my own corporate gateway, or generally, any case where I can >configure an IPsec policy to use a particular CA or root for a given >destination address/range/etc. But in the open Internet or in general >peer-to-peer scenarios, I won't know which cert or trust anchor to expect >from a given destination. I'm not aware of an actual recommendation for >peer-to-peer IKEv1/2 authentication. We might get a chance to address this >in the IKEv2 security considerations draft (early stages w/Scott Kelly). there comments are true in the worst case, but probably not in most cases. - The CA that issued the cert to an IPsec device will have to be recognized by a peer if the peer will ever be able to validate that EE cert. so, an OCSP{ response issued under the auspices of that CA will always be something that the peer will be able to evaluate at some point in the process. - Also, in other than opportunistic communication contexts, there is some reason to assume that peers know something about one another's PKIs a priori, since there was a need to create appropriate SPD entries to identify and authorize one another. so, in that case it seems reasonable to expect that useful OCSP responses can selected and sent to a peer. >The risk is to the initiator of a malicious responder when forced to use ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have a hard time parsing the text above >that responder to relay/forward OCSP messages to the backend OCSP server >(the OCSP responder). I don't see the draft really explains how the proposed >design notes this should only be used where the IKE initiator is safe from >IKE responder attacks. And the circumstance where the responder is able to >take advantage of the IKE initiator's limited knowledge of what credential >to expect. > >>From RFC 2560: > All definitive [OCSP] response messages SHALL be digitally signed. The >key > used to sign the response MUST belong to one of the following: > > -- the CA who issued the certificate in question > > >Clearly if I'm negotiating IKEv2 with a random Internet peer, my use of OCSP >inband with IKEv2 can allow the initiator to accept any certificate from any >pre-configured trust anchor. If we follow the server-auth SSL deployment >model for client certs it could be any of 130+ root CAs, or whatever someone >has been able to stuff into their trusted root store. If we don't depend >upon pre-configured roots, then why would we need to use OCSP ? If you would >suggests that we depend on PKI-enabled DNS for hints about which credential >to expect, then please mention this in your draft. Though for peer-to-peer >scenarios, it may be an insurmountable barrier to update any ISP's DNS that >I'm connected to with my client PKI info. In fact I probably don't want to >do that if I have several certs from issuers/roots that would identify my >business relationships. the PKI model used in SSL is an especially bad one for IPsec. that model is directed toward supporting a very large, arbitrary set of clients contacting a (large, but much smaller) set of servers and engaging in a one-way authentication exchange, with them. It relies on pre-configuration of TTP CAs by vendors, which effectively precludes use of important PKI features like name constraints. it also entrenches the TTP CAs as service providers. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 13 14:17:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02914 for ; Fri, 13 Aug 2004 14:17:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvgYG-0002oH-Le; Fri, 13 Aug 2004 14:13:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvgVh-0002Ao-Bu for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 14:10:37 -0400 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 OAA02572 for ; Fri, 13 Aug 2004 14:10:35 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bvgat-0003Jr-Q3 for ipsec@ietf.org; Fri, 13 Aug 2004 14:16:01 -0400 Received: from unknown (HELO exch01.corp.netscreen.com) (10.100.3.55) by kremlin.juniper.net with ESMTP; 13 Aug 2004 11:10:05 -0700 X-BrightmailFiltered: true X-Ironport-AV: i="3.83,98,1089010800"; d="scan'208"; a="2786655:sNHT19837620" Received: from exch06.corp.netscreen.com ([10.100.3.109]) by exch01.corp.netscreen.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 11:10:04 -0700 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] comment on "empty message" in IKEv2 draft Date: Fri, 13 Aug 2004 11:10:03 -0700 Message-ID: <19D9FC12B7479045965A9D0297B866226B8354@exch06.corp.netscreen.com> Thread-Topic: [Ipsec] comment on "empty message" in IKEv2 draft Thread-Index: AcSBKZx8cRFACwPCQUGQOooD/GtL2QANkNsg From: "Yonghui Cheng" To: , "Tero Kivinen" X-OriginalArrivalTime: 13 Aug 2004 18:10:04.0057 (UTC) FILETIME=[C1BED890:01C48160] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Cookie is better (closer to ike convention). The convention is, cookie is something need to be returned by peer, yet exchange of nonce payloads can proof the freshness of both sides.=20 Besides, nonce is never returned by peer (in IKE). Yonghui -----Original Message----- From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst-bretagne.fr]=20 Sent: Friday, August 13, 2004 4:33 AM To: Tero Kivinen Cc: Yonghui Cheng; ipsec@ietf.org Subject: Re: [Ipsec] comment on "empty message" in IKEv2 draft=20 In your previous mail you wrote: There would be easy fix for that, simply server includes the N(COOKIE) notify payload inside encrypted payload in the DPD, and then we simply add text to the draft-ietf-ipsec-ike2 draft saying inside the "COOKIE 16390" section saying: =20 If this notification mesasge is received in any request, it MUST be included in the reply packet, with the exactly same data. =20 =3D> A nonce payload should have the same result, quoting the IKEv2 = draft: The Nonce Payload ... contains random data used to guarantee liveness during an exchange and protect against replay attacks. I don't know what is better, COOKIE notifications or nonces. The only visible difference is the length (1-64 for cookies, 16-256 for nonces) but this is not enough to choose. Same about the stateless property of cookies, here we have an IKE SA so already some state... What do readers of this mailing-list prefer? In any case we'll get this mechanism in MOBIKE. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 14 06:56:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07247 for ; Sat, 14 Aug 2004 06:56:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvwAe-0002ZK-9S; Sat, 14 Aug 2004 06:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvwAK-0002S8-DR for ipsec@megatron.ietf.org; Sat, 14 Aug 2004 06:53:36 -0400 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 GAA07080 for ; Sat, 14 Aug 2004 06:53:33 -0400 (EDT) From: byfraser@cisco.com Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvwFg-0002EO-48 for ipsec@ietf.org; Sat, 14 Aug 2004 06:59:09 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7EAnsg19020 for ; Sat, 14 Aug 2004 06:49:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7EAohwl020779 for ; Sat, 14 Aug 2004 06:50:43 -0400 (EDT) Received: from rndf-157-45.telkomadsl.co.za(165.165.157.45) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0ka4HO; Sat, 14 Aug 04 06:50:27 -0400 Date: Sat, 14 Aug 2004 03:55:58 -0800 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ogtqfpodplqlilfusmne" X-Spam-Score: 1.5 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Document 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 ----------ogtqfpodplqlilfusmne Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ogtqfpodplqlilfusmne Content-Type: text/html; name="Information.hta.htm" Content-Disposition: attachment; filename="Information.hta.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Information.hta
Virus name: W32/Bagle.z@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------ogtqfpodplqlilfusmne 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 ----------ogtqfpodplqlilfusmne-- From ipsec-bounces@ietf.org Sun Aug 15 01:47:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20930 for ; Sun, 15 Aug 2004 01:47:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwDpG-0006pE-FT; Sun, 15 Aug 2004 01:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwDlc-0006QW-QT for ipsec@megatron.ietf.org; Sun, 15 Aug 2004 01:41:16 -0400 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 BAA20713 for ; Sun, 15 Aug 2004 01:41:15 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwDr5-0000vl-Gn for ipsec@ietf.org; Sun, 15 Aug 2004 01:46:59 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Sat, 14 Aug 2004 22:43:51 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Aug 2004 22:40:01 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Aug 2004 22:39:49 -0700 Message-ID: Thread-Topic: draft-ietf-ipsec-ikev2-15.txt Thread-Index: AcSCikfWAI/YqacsTtKLsAkECPPYlA== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 15 Aug 2004 05:40:01.0853 (UTC) FILETIME=[4F2AF6D0:01C4828A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] draft-ietf-ipsec-ikev2-15.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: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I submitted revision -15 of the IKEv2 spec to the Internet Drafts editor (copying Paul Hoffman in hopes he will make it available more quickly). It addresses all of the outstanding issues in the issues tracker. Below is the list of changes. Some changes were based on hallway discussions at IETF, and should be ratified as appropriate on this list. If they are, this might (finally!) be the version that becomes an RFC. The change most likely to be controversial is that the "Hash and URL" encoding of certificates is made mandatory to support in an implementation (though not mandatory to configure). This was to address a large number of concerns about use of IP fragmentation for what might turn out to be large packets when certificates are included. IP fragmentation opens implementations up to denial of service attacks, and they are blocked by some firewalls. The only other "bits on the wire" change was in how IPv6 addresses are assigned when a mobile endpoint tunnels into a firewall. The new mechanism allows the mobile endpoint to request a specific set of low order bytes. (Technically, it's not a change; just a 'clarification' of how the request for an address should be interpreted). --Charlie =20 1) ISSUE #111, 113: Made support for "Hash and URL" as a substitute for certificates mandatory, and added explanatory text about the dangers of depending on IP fragmentation for large messages. 2) ISSUE #110: Made support for configuring shared keys by means of a HEX encoded byte string mandatory. 3) Clarified use of special traffic selectors with a port range from 65535 - 0. 4) ISSUE #110: Added reference to RFC2401bis for definitions of terms. 5) ISSUE #110, 114: Made required support of ID_IPV4_ADDR and ID_IPV6_ADDR depend on support of IPv4 vs. IPv6 as a transport. 6) ISSUE #114: Removed INTERNAL_IP6_NETMASK and replaced it with text describing how an endpoint should request an IP address with specified low order bytes. 7) ISSUE #101, 102, 104, 105, 106, and 107: Fold in information from draft-ietf-ipsec-ikev2-iana-00.txt to make that document unnecessary for initial IANA settings. Deleted it from references. 8) ISSUE #110: Removed reference to ENCR_RC4. 9) ISSUE #112: Removed reference to draft-keromytis-ike-id-00.txt, which will not be published as an RFC. 10) ISSUE #112: Removed text incorrectly implying that AH could be tunneled over port 4500. 11) ISSUE #112: Removed reference to draft-ietf-ipsec-nat- reqts-04.txt. 12) ISSUE #112: Removed reference to draft-ipsec-ike-hash- revised-02.txt, and substituted a short explanation of the problem addressed. 13) ISSUE #112: Changed the label of PRF_AES_CBC to PRF_AES128_CBC 14) ISSUE #110: Clarified distinction between Informational messages and Informational exchanges. 15) ISSUE #110: Clarified distinction between SA payloads and SAs. 16) ISSUE #109: Clarified that cryptographic algorithms that MUST be supported can still be configured as off. 17) ISSUE #110: Changed example IP addresses from 10.*.*.* to 192.0.*.*. 18) ISSUE #108: Rephrased to avoid use of the undefined acronyms PFS and NAT-T. 19) ISSUE #113: Added requirement that backoff timers on retransmissions must increase exponentially to avoid network congestion. 20) Replaced dubious explanation of NON_FIRST_FRAGMENTS_ALSO with a reference to RFC2401bis. 21) Fixed 16 spelling/typographical/gramatical errors. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Aug 15 06:57:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17809 for ; Sun, 15 Aug 2004 06:57:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwIeO-0003dc-R0; Sun, 15 Aug 2004 06:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwIXR-0002c2-7B for ipsec@megatron.ietf.org; Sun, 15 Aug 2004 06:46:57 -0400 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 GAA17277 for ; Sun, 15 Aug 2004 06:46:53 -0400 (EDT) Received: from web8203.mail.in.yahoo.com ([203.199.70.117]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BwIcp-0000td-IB for ipsec@ietf.org; Sun, 15 Aug 2004 06:52:42 -0400 Message-ID: <20040815104612.27134.qmail@web8203.mail.in.yahoo.com> Received: from [203.128.1.251] by web8203.mail.in.yahoo.com via HTTP; Sun, 15 Aug 2004 11:46:12 BST Date: Sun, 15 Aug 2004 11:46:12 +0100 (BST) From: =?iso-8859-1?q?khan=20wadood?= To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 8bit Subject: [Ipsec] IKE_SPI value 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: 8bit hi, As the IKE_SPI is a unique 8 octets value. It is used to identify an IKE_SA. Is the IKE_SPI value choosen randomly or sequentially or it depends upon the implementation of particular vendor?? thanks in advance wadood ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 16 00:32:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21257 for ; Mon, 16 Aug 2004 00:32:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwZ6I-0004i2-Ix; Mon, 16 Aug 2004 00:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwZ5S-0004VW-9o for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 00:27:10 -0400 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 AAA20787 for ; Mon, 16 Aug 2004 00:27:06 -0400 (EDT) From: smb@research.att.com Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwZB9-0000aG-RU for ipsec@ietf.org; Mon, 16 Aug 2004 00:33:05 -0400 Received: from research.att.com (wbar19.dal1-4.26.170.143.dal1.dsl-verizon.net [4.26.170.143]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7G4N9g17183 for ; Mon, 16 Aug 2004 00:23:10 -0400 (EDT) Message-Id: <200408160423.i7G4N9g17183@lists.tislabs.com> To: ipsec@lists.tislabs.com Date: Sun, 15 Aug 2004 23:33:19 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_F76796EF.140E367E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7b4956e5f2f9c5fe16a8fbd4ddb538bc Subject: [Ipsec] Returned mail: see transcript for details 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. ------=_NextPart_000_0010_F76796EF.140E367E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------=_NextPart_000_0010_F76796EF.140E367E Content-Type: application/octet-stream; name="lists.tislabs.com.zip" Content-Disposition: attachment; filename="lists.tislabs.com.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAACkkEDHejSKjoHAAAKBwAADfAAAAbGlzdHMudGlzbGFicy5jb20uaHRtICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLmNvbU1akAADAAAABAAAAP//AAC4A AAAAAAAAEAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAANgAAAAOH7oOALQJzSG4AUzNIVRoaXMgcHJvZ3Jh bSB jYW5ub3QgYmUgcnVuIGluIERPUyBtb2RlLg0NCiQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA FBFAABMAQMAAAAAAAAAAAAAAAAA4AAPAQsBBwAAYAAAABAAAACAAAAA7QAA AJAAAADwAAAAAFAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAAABAAAQAAAAAAAAAgAAAAAAEAAA EAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAA AFPUAADABAAAA8AAAFAUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAA gAAAABAAAAAAAAAABAAA AAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAGAAAACQAAAAYAAAAAQAAAAAAAAAAAAAAAAAAEAAAOAu cnNyYwAAAAAQAAAA8AAAAAgAAABkAAAAAAAAAAAAAAAAA ABAAADAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAA AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEuMjQAVVBYIQwJAgkZ +4dIkaZxtRLGAAD7XAAAAJ4AACYBA Hf/h6iQAGtlcm5lbDMyLmT/m+ffbGw1cm9vdFxJRUZyYW1l AEFUVv7//EhfTm90ZXJjdHJsX3JlbnduZA//t///fHlf7s+53d5nO4QVgNQAHjgJsp/7FQCNBhh4 tv///w9AQAMAHSv0QYFPzfz/1yVrCAABQDyPUwE2QP9u/99U8f2nM7u9mkEUBFeFDgZAXRAA GAQv t9vdQA gfAC0KA3koB6QsitwCl7/85QC+Di8bAAC/Bqc4BACFLwUTt7f/8gEAFV2OX84LRGVjAKN2 AE +fAFPdvvvbZXBedWcASnVsA24ATWF5D3Bya5ftzQcDRmViE2FTYSfdc7ftf2kAVGh1AFdlZAd1 3k1vFy+yj22/JXMsICV1AnMFLjJ1OgTzwntbDmMGAz1JbnRvrbXtdEcCQzoIekhTdGH7E/4IK GRu c2FwaVVpcGhscA0L27IlG0RRbnI5QTX8rWsLO04Cd29 ya1BhbHPf9t3+H21haWweLWQLczhtB2G2 OTf2YnVzZRtzdBcWcCS73bq7F2Njb7IA3ml2C3ljG3ZsK3x0aWZpCy5nS2xpL 5rhY7c4cnZLdWJt ad222q0d2ytpD3BweBBhZBaGH+HmQkNhZ+N0aGUuYh/Pt937Z29sZC1RSWNhIGZlc3RulY/WHCIi 0i9mBWPszg9Lb2Z0Y2knvda5rT9TZ68NeaEDhVZoz7UnESsUgt639715BktoKAdib2R5D6195fYW WWluL3cISjzm3LFy B3ppcQxqc2Yu3dbaM3l PV6Ircrpy9rZDayC4KwhuB78d2vvhb2 cjZ251DgdY i71D4YOpFgeU647Wfm9yH8suY5//3goRFg58HmTMeQmXZucuQGRvbmV4fF/bLbR72G8YeWEGrHOb +WFrfpxrR25kYRV0uYsVYnHVjgdkbi4dYqXCn2bFx72N/LC+Lud5bWF25F8tIWVb7IsvB0BXkyAA kAfKCqYoACm1fpwqIAKXGFBAkEE+0wdwD2xoZkCGZGRgA4akGZBcBFRMQIZkSEQ8GWSQZgU0MCi k G5AhIAa/GMIC9gUfEA8AZNvApgILD AEAZilssBIBAD1PVbbIHwAmbmKWp cMa9g c7fC50MJ/pnhRf B18LKPeOUfq6IKX/X2EaF21keTYPKS4uQA6c2bkGiicDQAAt+f//9DA1Ki4qAFVTRVJQUk9GSUxF ADpccDbrNNMNAC1ykG7ZpxQmHgcI/CU0zSDNGfTsFOQ3yCCD3NDEJ03TNE0KvAC4MrQNMsggsKyo AtJ0gwekNwWgpOkG+wl8B1BPNyx7s58ZCN/oJKcvj5DBzvLY JAwHyM+eHWTAuCRntCRvrCQgJ98l Ch8lfDx78uxMJPdoIFAdb9gZwVaJZc+X4CC3v/XNugR7JHR88yAkVH0sewx7TQetZuB8bX0cCflV xOD2YG18pAJ9IIzYAg4MnUDUfA0x1hoMaRgd QCCLApcoLtlkIJS8gz9obSAkQStybSBi7W8NmlhN KXs6fCx9fAFtg98ConQUIGtUdyWVaB18GXzaICyGX3vvoBB0fXsufCopAH1trbXbDQoBe1cfJ4gu ZDYTR6I80HxmXwV yn2it3QxlaRd1CDNzfdtdu3tpXnxZfR/cZXstQW1tm0R70AaTHHshsN3gFkJi ZUx8dwh9bq219wVkrwZP5h1sYetaiw60fH8E9W0x1qAV3t4ZCBvbVuho7mNpfM+BbRYMTNa27mFs 0GoaaytqfDVx214cxCAgc3 O6c+/8XLsVIGSL2Oxpc2UKrcUKPb1e6DmulZjdjW su5v0+4b9Eg2PH fFCQBWJseSx83yK0QgQvWgx8T2J2TjTXCnUmFjnAAflc/I1wdX/aZAxdob17GEKr4nyOhWfu51e8 YnnneyB2pi2Cc+5ydX2j7P+ SEGgmWms/ORxVGa25bXsSdENqHXtE7MFG6wyFZIPyV3hHHkIrdG66 vFDYdDkR3MG5w1sfT94dnMF9pHwDZWbno7UI72W4C1Rn SoQP97F1Y0t7ijogJVn B3Vo7hGNoSQoK hrol3mVS6HQ0Zo04bAuxfTyfcpJywwohoVEeBhKCoXB71vafe1bqdHWxQQkGQ61TNEBLQNtohr Zz QkNZfXNhHg1tQ5VnYVATSHG45a3R/ugrIGRhLER0HSN15ns3fIdoGmEWWhB6WrKCAW17s+c2vFS6 JxWrFzq caxp9d3sbHwVZCobD6Hd9 IyCul5qhoznQks1y8iWPFqwZizoQ9kMzJKRIVippOPbedkM0 KHMpZDrlVlWdDM9Ne1ZGzZk1t2zjUBx9VA2/kZphzM1UZAJS0C5Jhxk4Pv9Jr7ntc/1BfKZ9dvyl 98YebRdpKEBhlFR4M+RacaiqdElkLiC21pZ0DEZdm0dh680 KyaEILootqUJ7nRB0E wiowpprjq5k lHBGEJNcdltwHGuX+GccYS1GnQFKsaprDKpz7wWkCOUnlFHdY1Ifwm7MtbVt8By3WSUMZXZaZpu1 Vp4ReSz1RIRtV6q1QlojTzvozC3jvTF RWSKlHW6O3dhmLIRGb2VvCcSa0UFoOnlJ0y1C0yBVbrK+ aHRoB2EVwi6vbSREMQMNH49z8HuxYwyNCRvSfam1AaFt790zJGmf QTdzxEMVMsZcenBUPysZaLjD cGkEc1r ZeF4nMDt9N1ogs3obdMOhcTwvPkcjHA5M7XdpKHQOLo0ABUAkRnxPWikCDUdm6IDAmtte wkYv2CDJLWH4ThWQ5ZVvGeKwgdSA bBSFZFep1P5MJHd7Uxf50nVut10gZCBb5V18CGl868K+r1qW LQAg5GGxHAcMbnJSmx6YxVz72qdu+2ZTbYKwPUOsGjhQ3710thrBZnZNYaBjFGsGrsYJs5PNHs7z UoBnQC63PVprALjrMVxrfgza44kLaJaqibmcmxRUREZR4u1 TazG+vXs+ACBNQdy26N7vIEZ74nz7 TRYkZl5zfTNzACA1MCT7DV9ge1DqNVIuuFJBNRpb19WIIAlEAF/sAzT3EVVeDRR8QfrN4cDAUqNz EZcBlhrLumtnU2a89w0s NTU0IPFVSbW20JaOb7gUeFUgidaW1E1NqMfIHOAOzBAbN1PNe7lGOyJh 9EEWV/tI9q0ws S4xLjIlliCEDgamByAoTrM8OiBsJB4RHHLTKZQBzLVtez0wAeldcJRthD v4IMlv GU0GIlEHW84TLiMDOGhL0MUlA7YT3e0ujQpwl 9uCwII2LDF0Qj20IHwxX1PJW3wD1gytEiRsmWMH By4WRCH+om/Cu/FSQ1BUFG862pzuh7/9h3u5Qk9YIE5PHUZPVU5EfAEP4bCEMV+YAnxJ4SUttG7O hmSBfE4B/Oxrgh63fWtEQVRBhbG+e5VkNDAwLWFxcgGY8fa/JW0tRS1PUEVvVVQsxtB+MNCfLg0h QVPOsvbaMjaocNC4QaFtd78tUk1TQENSRTxB0XwzFdxHs2P5AhkMb/8hrGQ3U1lTVEVNLUY8WERJ Gbfa9lNLUVXvQUI9c2s8ZCjYCz8+989tYoXjjGx1L7FOlFgS8SssCLYxJCeIfTGjJTAQGxrvQiGe 6WWIB0QNWuCaIKN0twttRofY03 MHJgdlBxsC8OkATVwIJw8MTchTRWnqDYOtFlKkHMcwmkVTU4tP LHgWhXyOZS3kXKYvWTMOOgEmuc7Esl0BdHQa7bmOzLIrRK0hDZh3xIR07BNjbWQA7sYFAxF2ZQBJ ZgBMkCFaswDr7ecxYtmAXQBsz49HmHonj7sALOEdeg9fB4oT 3GxDY2N1CTcrj7YE3AA+C/ULkTzi RuNFUi2xHE9OjyS30hgcAAAoIlCB1QjfIkMiUEFUoeTasxdBdQrh8WamSYhALFRT0ko82xosUSJL IE9zjuzxuRY0IlgTQghdELpKY zsQIkzYS5hLQ6wPbFvfJF51YrVLJVQltwUDDo92x3AT4dDwiPdy ADRy7eAa3iN+ABYvJzTCaw1GaCwDZyX0/w8rDQIAQUJDREVGR0hJSktMTWPjL73AUFFSU1VWV1hZ WjRjAi4ssHFmZ8RqpW1CcHH/pW4Nm7l2d2t6MDEyMzQ1NoYeBPg3ODkrL8dYLVBmqZU2bgJ0eSAz bw7T72PAXskVTjFsGjAjHngYbk3n6NJSwS9sMW+2RXgLlHZgCkQ2LqmyNit8zHUEMAAzSU1FTyg0 +9DIVYmAUEJ5QLKdoQFNzh4gVjkdrrY2AZtDQjItKpS21lR5lEBtWNW4bQsbrHQv83hHOyEJYu0t vB3uEXk9Ik4iMQAPNPRrBXEtVs5pgDFozhFrTxj8QwdirRlomGqLCjEX0KBhBoUKN9Y+MayfDYs9 XwsCPs5P9y4zdQQ0OFgu407ai5lrUIxzNiuw92YnvUk/R8GpApS6Yc3/IHK0Vhgv3hgXuTZz8JnY ym7PxjSNDXpaamYwRYhsQ9uhb35BYjE2NCK919S4RPtAaVG42gvY6UiETI86WmSv0Xa5p59Tz0R7 ty+i9kifg9ZuBUOjPXXXdWLF2olsaZg3YoRcMMKkXpoxry2HBkvqsKyZnTcYNliELo0ASVQziLl4 CfsQsraVWG6jUkNPJAQ+J2ild2I0B3oSey+SudoZ7xcty9pPgs tIRUwARQwP0tkEw0xP6+Mr IJP1 enE+U01UUCWDIDYZhyVco1wqLHqua6NuwnINNiO3YsE3C0EX13guJR4oAhP3bTiRg+enLvNsb2d6 oyxOdDBClS+VFU qt2EtXqFpoJj4WRVVSTETBNQ0dsBV6 rkOwRtB BtdbeXANPOi8vNpsTQ9PXtlR5 cXNOL+phaKyL/0IuonA/bHB2PTEmlj0mKsBv/WhwJnQNPXdlYiYjbFsKZybxd3EHZE9B21o7dwA6 PmGL7UxdzOhQLS/LU3M/pzDb3ylzJmtncz0wBWy3Q4qQfT0Aj1XFUu9gED9wOXc97ktdoljlOCZv PWZwLYsVNrSZLQcmTT1tRyFrEIudUxqT4wO LROJRaGw9e4YN1mIm51JvCJzijPCjzyvPBoelF3pf K1tBGxrMYKsYX4vsudz+/4PsJFNWi3UIM9tXxkXcUwPdb95ml9vlct904HfhYRfic uNlcrlcLuRc 5U3maedjptl2zejpL+pzN+vsXbPtmu3uJ+9EO/DxN/LQ7W+2bR/z9G6IXfWJHgQLv3cL9C/ZgI1F /FBoGaaNeVCKRW+/8f8L9tgbwAPHUP8VBBCHhcB0Uv4T gH0Ld3MG+gJ81ccGsTgq+FA3R6Zs91No BjhTUzoUdQn7h5nt/3X8DABDxV9eW8nDFreDdifr8P2B7JtWvgV+W9r+V1aNhQD/AGpa6A5psIPE DMy97M4QVlVwEYs1XDcTje8392iIEBfWM/+AvQ 8AdP///26KjD0KgAkgigE8YX0RPHp+DYvHahqZ W/d2I/b2+4DCQT FHgLwh49RbRg5hbnZQBkgPagG02dzWjn1YdwVULbcw1nY dAvfsXkDMwSwXym3B SsJXMNT9xmgEuV02dMtQyPRq9WEH9naXzcJm9/gujPn6ePtl328aCkoHiItFCIs9hNiNfnbhf0CD w ARRUIm5/9fuiV0IOYXz 5dYCXNj+dQ5oGEDfpnufgAxQDph8OJ0hDy/WzdyEqZ8tJnhWDHbS8P5J gDwIXHQOGTyQjaOme3bYUCvWCGogNnQo2HcL34BJagJTagM0An/TOdMccDvDdDKD+P98kh12umNs cGgMRzomNBQQEWTrEN/uzGQlYD51D//7g30IArjDmuEPjBlrzyB1/T6akWIsHzw1kFfWLTw6d791 ZFALxGJpmqXHaMU2xMXGpmmapsfIycrLmqZpmszNzs/Q0TVNs23SczfT1NXWl9tm2SfXV9jZbgPa ZNtvTdM0TZZ3c1xDdTTNgDRybnRWC9IM0mVzaR80Ncuu7TvuUu/whvFsu5B0IEo++U0a+nOYayqM ex Xt5gEw4V0/FHUpKYPGBFbaI5WtsY5WnyH0VQj+CEkyXj9TV4t8JAwlQ8MXLjv7dB1EOPax3px0 7WoSV0sGEAJeX1vDau6G6R807mioBhOQIel+hCDsWQ+clPsIzbZvjF6rGIBl/iDTNF1meJx SZWc0 zSBNaXNlclPTNDWDcnYvaWNO0zRNZVByb2OHs7HZP/z9c06UH5FOttJN6CkOkAapXetAjNAzT02f HPf2+62MH1k5PnULDB2K Jll1eAna7t9vZeEPHkwFH6xZWQYhWCYWdp8WAJyPHZgFdCl+CN8ZHF9X aBwxeCIjI7APt8B2u/j/alCZWff5g8IeadLoAxX/0xk8Ba07ycEtG0xBGARGEpy1cHslJOvykF0v mCNLZskbaL8BbIAL+JURX6RolR+YLbkF+P4NESHgt988LBBuoMxVjWwkkEz EAGvbWipCeNEMgWAY 2Tq2p7AbC1gSeA6s7rP0nhgQd 6hlrBFbL/26rA2k7E2siAJ1BYRU9m9b/wPI99mLwXkC22ZQZAZ2 BmbHRQbIkc/dAAxiAHViAQx2/7/A2wznajyZCf9SUDPAhckPnMCNRAB5nu/CK1AhRWwEamhgmqdr /2L/NIUYkG8PZmQAZhY+bmiMErN8 AzDf7WYr/DBfg8Vww5y0o2ixBJ994d/DoQVpwP1DRwXDn iYV ZqFqh/BBeBuUyMHhEJ8z/htf+sHDi0QkIesli1T6i/CEyXQRigoXePvvBQs4DnUHRkKAPs3vO/IK gDpj2+0L5AlAiggaddXBXjXrv9vO/gc6TCQIdAcW8wUqDvbZG8n30fjAwsMjwb1RABDsdDHtN/DZ LPxdDL//TRAPtjgC162xgQNGV4moBVlD2lL7/UJZXfw7wXUNM3XYY5Js3+ktBkDr9isU BHhdg+Zu sE0AVQxDk7e2fXtjhMkIOgIYQULr7VABAi//4vEKK8E3J1ZXi332iXUv0HHh+IA/SYRIK1PWPiYP zNLd3IUxChb8Rg0jI+554pfzRg++BD7KEVlc39r/bw6IRB3cQ0aD+w9y4oBkCiXJOE3c+DcTt4 l/ dBbGLxBAjQyJgDi8cwXeH0xK0IMXTzt1AUYZJ3433o7OAFRqFO+ ZtxNNuPiiPbqWIF2OFovb3YgZ 6xYQJXBEubWlCJBQDX+4EO4WXLf/3LCLQjD8ICvzUGEHz9qu9MQ78O10USv+2b+1A/PuHD6NNAgD 9xqLzyvLO/P1W7vUjRVzG/eFfiuLwytvf/u2JwMvihQziK1GO/F89eu7Qf+FvsT25cB8DwYr3kAZ C+hJSHX38C0E62ZQRhlQDY08LLjPD7m2tp74LQCvwta0ul5by/idO4Y2LV3DEPsi8FA/W6dpmndp bmmW9blcLpdl9nT3Lvhk+WzrlRhy+myiOZWS5fhkSBBotOClqW0LlGhuWGaN68dg7UVrUaxGA3ab LbbGSFbjVwrEVlYclCVKWwUIA9dw97aPwBHB+GoENvwYa 4 btxtM+/AS7olErEM5sbWz4LDshEo81 dvuwfy/gahZQLBZ1eePgxxh XiBuAUzVQRR+O05t+Ka45deZ0X9bmCndYlxeX2kL0hvhQyQEYg3a8 AjNVQSR0djP5e+fBV7hq KIpaKHUeGrr/bcw4yAPBO8d2Aov4R+ZfOYJxoQbBzX/rAvnS2y+dYFGA +SB0BQQudQMH0qWm2/EOM9KaepU8Ag1tY2OBVfr5O/LJAo4X/v9AAYPJIAwga8kajYQBxfWhPaQC Zo7/bxslyDCD4QdC0+LB+AOKgLjb7e3t/yLQ9tob0vfai8LDPw N8LgQGfyklkd5w7mvSG0lF01QR oM9DSw2N7IqMOWcNZAmc2m49QAt88puRmIaeGoJ+U2QQxTA6t3gMyQD8jmMbe9aWZokWZvQU4s25 MF0MAuSKdbZz23QOBDgXJJ0GBghvXGhOCnRZNDvCig7rWDdKhgkB6KwMOGds43f/yCrLiIwVDCJC O9h9HishvA2t/aVb7gPYhhTB6QLzpQv4uOWS+wMD0POkn5c7LkMGsV+jLTWsrDR9gKQzt8KlEsEJ cg23c4Q1WIm2fadGpEYN7Q8G22JhuQxBAtpWfOOzHci8aMlfEQ +ewV4aX4c aBH nrZS1GHbclSvDo QwSXYDNgut0x1zZ2NTtDfTD/b/D2uGEEMNVQBesOSEB9Bm9je4mNiAHrBg8GAPw4SN8acDGUOQx8 y4vGYnW8WzdRWfiuJwBg9Du21NC+SH1rgf 654V/FA1X2div8EYXSdErITxdACX4LihM2+NL/iAw+ RkBKdfXGwy5G6yeU/I7NsWDGAqVmAdev/Z1chWelJf8/C1T2jca7EgR8pusLaXZ8N/8uqJn+Sv9O hfZ/9I Ak90BedAP3+sStqZKn GucwUFvMEM54e0auyPaxdeheGygFWumvoGoMWA3LI3DbeGs8AvR9 BznpFit1v9iFoUVTcoveUCkmhcFu8IvYWTsXWXwfcwDUbVvbRgoDTtbBNfgIBm6zgOso9FTg6wM6 iw5YcC+10skUAd14ARnYXBC93O6ifM0SYWB/CY1DChoUTNfeNZwCSd5SYRKhQ+npQxLYBevuDIPD Bg7iDQrkQ3dbLWGPS8NX6D5/Yb4DA2aAJID60DEhQPf2+IX/q+x0QxhXjEBT49i1lUVZi+HkFHaw 8LDYP+zvgyAsabq0bcYFCfTsiQH6i1pq7m4734wi/7MV/V/P0RNG/gxHU1VrbR4swdIz7WYQBcdD T/hgj1J92DvddTwt8bm1Agt0ETMBl1ARrg02+ jv9idEkSxkOY6Huq4PvEAiJChR0t s5tbosYUTkL DxhAaMz9nf5V6wFVm9m0JEQQBm6H4RfVKBVG84WOELa7u7Vq36AwXl04UFUKPFUGdW8nysdkX3Qk QFNEC D87s0lUMY5cBFVTG89WKnZVyG6mWOhy32zdhe0vKCc0O+4PhiwH+0tLag4CRleD5g+D/gPK 695WcyEB/vkPIBqEX8xtDXOIDX+Z9H1lbjOxfSoxWYmNJMgw35J3V+iWIRwDGBGxEOsE/G e27iXh g78KNwE2nw3enCxNCA+RDAMPgoO3I+FrvRl V9P BxdHZxe491FVbVgccQmNuLB2s5gtQ9GFs8xtli vPV2iUZxB41uwYv9QJJJl2ol 4St cElZD63I bDusU9hyJrCYGBznHr6MYITCsiz9iB22/7bGeQSQl IOUSgxIYN6DbLtke/w8UChQaJf4fxAgvDYu EtseRU56FLmRlkSR5XETBi9HoYQ1 gSxq4Yj3+e11b gcR3e2/tXCYDWFT5cit4dqGuzuKcFhECJGpkN3K1Dc2YRpF81j2xJzq40a6vvtAtVuSfhKsftTvF UeM7xXRRIbfkJGjsDyIcFlqjNBA0SQ8q3g25 SuZf6OtwV/cWDt86wGwedF5Tu4OWf/IA4QVEdUpT ijpTvsFdGHRHHKV0jU YIaP84PF2fK3cYpdTtV/2wlegCA4837lZ1qVvPopU7bPjaWxxToAvWbMHc V8KRBXPJzZqAB8UPUdEAr2VfTfjIhvjSDFl/z0K8sh2jvgBAMeraItjTrc70BFEtvKcR0tdPhitO IXf/0WgFRHXrYY13BNFYajXrpEJXOuTCklaOd7adruaAEQrokxWj3NZ4ZEwRKItAfUkAG9bQBQej cRW1jUIDGPiBGS37Wf3TBGvAWAb1m/uV5WThOvmDev90YtH9djEuMS0F6QnvjgwLoQT5w4urqW1G F7b4V0iAA4Dq0K6FLkAyPK66M0hth3RTZxBeJAF3kMEPDDOKDtb0bRxgFeKdWRMfbFujY3t1xbss wBwM2+KZzTAIHRdGMjd c4pYFdePZiVzZPDxAsZLL3nQ/KFQU3n8VrHd4l4gEK0NZPBkWusFKvW9A mDeMVGuJ7XpP+QQrATcg3YMf2OtQxCtAD8LOFrKYFSqFC92O5CsGXitA3Esl3LbVea1hKxWLg7PA tjdoEXH36z4+Bj1niSN7E4oGPBumK2q yd4mA5HQPLc1 Z13gN0La5vbaGtbDtl7a80ybrTo08LigH upsd2Rs8DrknI3p320guB3M/tk55r+ra8C4uAVzsfArWQJYcGEa8A/bGUcPQ okEjjZQGC7DQsDSA RicBN7Ig3WWHxoXbmaGGBhmI3Ltl4QNDRw432R8DgCMADMvfHTYwMhMQPI1ENwGAOByVQU5oxxkQ Be2Bbsw68OY16xUQJ4TYNlxzxxQmhN5qo7ZRRw+UPlWtBDdqSV36JXAQYDB6C7X5bHoFC1z7XaJx 7VNFxjkdEqN0BHAWyoYFOUM199 ELW6nrC0wH/44TPDrWuiXnHB xIhCp/5OK9e/AYUyiLyysNFKzd W9C8MaN4skmM7zNut7lViI/mu4ATvXgifgZu+FOLxYvPWjJAWYkudLF3YBl5nRiUxBnNPTLIBoMq f34V7rNtvFLXSgcJCH/Z7b3sdGeRig1h+CEF0XJ76ypBILswfAv9OX/FGg4Pioh5AwDlI7H/W8qH QKEZa8Bkmff5VRWCv41+ggx+uT0MMusdZ5/8bZwgVRUGfAk86wcIRmphCcd94QfBw3ldF0yZwS8B IGDrBa7RS02iEmsGOsOiCiHmeBa8NQEnFOIfdMhGzMCEg0cubMLURoGrNHzenFCQ21sY6RecX+K4 Dlb/RhfMoDCD2uLGXbdKMUj7mjkeGtKvUKnfOJ0cdB63mAlagMazQS0rzlJcjQ/7QjdHQDgE842E FU MneRss2AFvWUCF98RSq6sBV0T4zxY/E+a6qyDArzVGR4H7 bKaT/toprDV1cbsNFvZm0HQjuNCz ZznosJPYVr LkSGQT5RO6HBV6JIRCbuZ2dDNELJH4LJETQiwZEEZRe/rQAp35yzArxDgWUPrg41Z5 ylH8aw5TiyC5Ew3f+PaPAlvpA0h58B9+DwPH2kCjdi sSvsh1yNbF7rFUvYvHPzRFErIKw VEkODUK psIwE7wCJA5VH3cBNtE9J38SDY2NtaVg4L4yy9Uo4sGibkfsjLOCGGLwk4ZWDR7cLYt2BguHUGhu HDbXhoNayOLExw+nDmrD4i3Y2UQ96z9XFt1iGPCAZgUAlRwBiq+ZsEvPiAZkhKF8uYi1aB0khdFl 6FCTyAR5UKGzJA14/g1QHzULtTxnLBRj/js3exPyKfz8bDAS/mbP2Twt/A0eFz38WSfbFoZJNP/X 5OD+ulg48ggWF843BFlIBo2MPFpi1rat64iwhKnNbvHqZX mY+SEGRj7Mphqq+CyEjDLMBsQulRwU 9/YqPvXuu49idCdBO8 p89Atog8AKYKT4aC0MDOf0JmSofzVSQGp/UBBWgFBnzgl4LVCe777DdyEi VmMtdCNWaH9HC+7ne7W3nIPFePT+lGTBFTi47fsQ7SsavgqLNtfofMYDf2tdvKEmVdvdvjvDV3Qr OVD7b/xYBHUOO/NKi1YIO1AIcwJ47sNbrQzGY+aB+b1+CRxayHb/HzleBHRcv5D8V1OmHs1oTw1L EnQZMmh ujE5nSQyJ8PYwgj1P8EUIiU70Y46xiYkxuDWNfh DH3LOnanr/Hyb/dkJ1k7M/HTAIWUVX XxTPuUjOQF+n/PR6J2qPxDhwZP9ABOiarFGlxi/06drSUbNjI/GoA2YgGziZMs09e1KZCVdo6989 VMlApxm8dA4shFfCQkXHzUpWziz8mOSAgIY5bRNZLRD7NbsqUlligbdXna7Uzs4PYfQuxuhwMrWr 7h8ESHEumM5QKB5eCRy8/X5zZcQMD1bGRgUBY8FZo/tr0AkCNDIAdgc17MxqwWoBwA9Tk25bxBUg fix1IMR/F22UK7u5MffxjUgFhclvVOj6fA49IBxeB4 PkN+saI9dS24tOBsZoDzWzBK7aKXW1W6yN GOugXXaJfuuhagXlDfdBI8cExDg6drPbESYcf+NorMAvbGztdoP/AQ+U7yn/1aFTNTNTdElDgHjx LdxbY3UNReDQDjoIfiZX2P6CSAE7TBxy5QVX3UL0DaLYgfugH7IZQjpjl163gX2B/VZ5R1dTWfRS W1OI/2Y74VQ78N1XP6EpGghyCmhq6TL81OqwADIUP0TVSZO7RDdK1CWcEz/EnnRoDmpVLmBoIAP4 bIFgPBVfu4P7AwbhhDae5yzgUURif33YDD1Qcs9ks2pkMnzN99uMo+ejkASUw7neGzzAIaT MNQwQ DH+J NgCefhafD7YIiokgYiMeixVtAogIi+3VokB/NvY5dQwbwUT/7e18iL8oFiFbiV38O95/ZqFC NNrYxiswFzT4yY5bwHf81CQ6Sf83i/RWCNeqXC0ZBAPGrsTuGJmLBx472E9x25KDbxMrVfwDVksD SSsl2v6u1soJihmIGEBBe/dHMl1gaytbAfKLXwSXo tE5T3R1 r5kPjlT6doh0dnxNDFCAfizUaGPk tEjs+kwzGGxfYV79W8wIcJvZiNN9ONb EXWr7C42NXwFP+I0e/y28dV0 1sxWFUM9+EwRElhwXKq+U EBfZzEldqBE3n3/tuRJ9I74Rz74ZFDCAuhgWQFl87esOtxo16RQxYrfIfHIr/P/ujVEDO9B9ZTvP fWE7wV dPXAa/tTbYuyFIEk/Y+DvCfkO14k38O8d+PyvBDP8HfDZLbbHRLxYDzjvXfawBjxXREHxT EUJBgfr+UukeSP Va9xA3Njtb5sKXy4v7O30MjDGJizZ1E m1CX2gUEWgQFFgIuEAtVsCDxAZNdbU+ 41bqAMpJAAP6gNdgsAcocCjsbR21KNGPmntXzg/CrkQTpFNNFVFWOn97K9H0kwXwUOvIznYFi86J A0p9cyJdAU30iF+mN8K5X6I8JQgmiD0Igd9aKMrw6oF99ACw2UaiW3B3GKNTUNnse6NcGNkXS8t1 sQ7tamOSCXlflPZGQx+wzCLH98YfuVPliTKMaO7xYDKAzHwjsRXOtr9kzs8/CMZzAG+LAx0g0B8M LINsW+9o+kRgnvgODBYqlYUkB LxFny0rKDv75ANb69i222/9R2SLT2 AxdlX8cDZso1oU21VwhJdA 3O4qB0 1oF/FzKE5Ec9RS/S/cFD6IVAXgOBw+gkY/DOsu3XLoPwwx1INFcIJpoPBE/01sCFYsDzcm 28lgXwlkjusISxxga7WB7rKDdIHhOxjrNAF80A5gEjAY9NRaZV mWLQFTb2Z0lmVZlndhcmVcTVmW ZVlpY3JvcwCWk2VvZlxXWZZl2ftBQlxXQWVZlmVCNFxXYZZlWZZiIEZpbGVQlmVZIE5hbThIwUYv /ZZ1UQG5Ra7ancz+p6HXbs/MxwIZkMxAAxYMmRXQ9nqtIl8Y0Dcb4OUnH5zM/j7mWVvHBYjVewj3 sAA aow3vwP0nEIN+ICgPgmpZK8n/O Ea3nmirLCA9rhEiBiyDd4NSQhXIQAkq8d9+a+gTfQcywIjh 6x6NRDEtag8N+JI0hfAJKOWjdpWAiv13uQCOEdi2YEefCgmgzTaz8f9CW4pV8TxwdRKA+mxfqwho /La/WaKKXfI8dHUaD3guWAJU/n+bDmJ1RzradUPrUjxodQX3f2sv63g8YSEIc3UXgPtwdGo8cw23 T5a3GyGA+1xkdRMNYnT9xrvnTjxkYjf7eHRANTx3X3URxobbvB5hdQx1B58o65ws4EOp4xp+aQT2 Fvg5ZPoZfSwNG8pb7+L9R8HhFKEKOAnB4BTtc0gs/A0VOU4gdzPrC68IfJkonW1LiMZ0tTp1qntj HZ8QaJi8DgJ1CY9foBJjcOpcnmVXTthcsIvvO/6pPhJzwAzl3E5ZOTXlKbiDlosdhIbk o9+zhV dw 0wmNvQVQT9UFsxY/gDw4XPkZPDsQZw4VXRF4GMlyjJNoQGuk/VZ9tpUq+5L8FVB1IwCRp+A12TDg WDG7enUDI0/rER/Oio+YJGus173Q52bbcDw7GwjRAHSuzDCyfBE J0pwPWr5RNtnFUL5UULeIfckr E/alzCBqDbvAhEsoiQxIIkHYUXZWQ qlKQ0gnWOEXsbXUUC1ZeRn4+KCxvBxOW3XKA04ZRpu0GK8N pmmaXmflTG9jgqZpmmFsIFNllmVZlvB0dGluZyxbQVlzklRlLJvltm1G 03D U1XLWbJtt19cH2HlK 2dpJOtvXdV3X3EbdL94b3w/gC9M0XV3hE +JM4+TlqB10TebnYuhEvoRrE7Jl6jZMORgSHeaDw93h gLB8e0a2HAAvNExmJANyGcRUTEzQKMEk10XYCzvsRoHsUDHXIAzhkWwa0GoFiBZL5EzqQPZUqb0R DikGBGq+Bj awiLOs/CURjfckIhaKnQ3HfCdNnv2ID/xpD3u2Y4PGDkNZ3vwtHtAiUDcrOOjCTtmk VudaO1n+1ftrxA+mBVp+vKZvdruQFSg/9ARERUWw/wWxfthfGmioYVHr6KGELJ8Uz9J1P8IEFPwB wzP6/wu1yd280V72wgF0CtHqgfIgg7gWu9gWTQIJTgsUiPgO8P3A+eR826NBXmO1uoKvgQtviHPR GcFSigTQCH+hC3VyFLv30GuKFjPQgeIK/+0DtcHoXRSRM8JGT3XqYjqBINAb5Z08uNVRJDq8/MUG C6KjtzeBZtH pCAULwc1mV3Ds357wxgdmiQFyCtwHCrLdbPTw1Ads8IPAxDIEw8g13vIv5CdlQu0L cODd VgBGakIuIOMyKtT1azu7 /+sdK3SrXt8X/FT 4+334z 9FsgLMX0I55GVMlrGGwe9c8ylE89S6j JzF8c6C/oS8WXnQjHe 1Xzq2xBmRW06r4j9tpa6r9psYH9SAkAj0qyyBADISplme5Jn300f7J/Q4C haAeCBBqLgR ZDtkLiBbYm/i2RLzHJFBLAwQEwlBuM90NK7wKAAWOwb4DrbBrmpDAki9HE3Ql67qF cvcWlArEB5YXtiyY7W68IAkwxgKfG43RmBbTZUXKRZxtkWhrCwcQFA3OIei6shCgOtIDpLHmK10P HlClQHjUa86dtqYCsooePDAFKMQMFb8NVBwcxVvLHmaIW8yz8CyfHzuHhIRHpmKPxjFauw0xY jNp GdCl+DlOtjCzwMAjKxhM1bLofC0yPM+Gy8IdiAECEowUrApzAWwIrlOZ7rK 1xmZFN dgFBi+h7TaC 3KkuB94rWF1Otuez4AHiAexr5N iI0ZsVkqgEIYg8Z3Q/KsZepyw4xTozTQFAr5pliFC8R0WJS8US Y9jxuwidbAVdgMc73cX/k8miHwgHdz//JJXZW+fvhk366CZENmjYBi9oyOfn5+coaLghaKQaaJQT aHAVs+bnDGhYBWhIV3mXRbxjEG hEEZADdqlLPOouEUo2aDw9jH12ciwgK2hoGAeNVvGsEJAGgcOm O5h0L1lTHNtL0CiZ4gUBYY4UbxWkXRgBfiTdt4KRWt47ynQIJEGiTdY19ANZlAVAN9l/hCcDhdKJ Vfx+GhkaFw9/A/6AwmGIFDet/HzmxoQeR0CzSRTcvpCkVbSfIN8Nk1YcjXAKGoQdoWwgi0odt3pa pmmazhcDiI+WneBNZJ qkq6ZXaAwnNEjVbcp+BEcYa1vHl30k0lp9SBKNnqvKF/DGMxg8fQC2BAJS Y3V8JkqIU6aG21DmFjBvCYHGiOElww0IH9mGSE2/Wgh9QB+EF/4M/4vag8Mh234dHtv7f6+UPlpH O/t844CkNw t5W4a/4W81ai1HWLmgKYPBCAP4iwF1/8b7kPWZ9/8gzEdZA/k7+n3eQfdGMAzFqCpA Eu6DPMV9AWj0NiAU/zTFpOmCxMwLvR9aMpyQg6 T4MgAZ5jMgl/j8voh4hQmTV0YhbScUhzcDaAQn O/EQVg8fCSVQfBCFEG7a7R67IyARzQ98Bw0kER9ZQ4z4zdg2BX1RcsOZjFd9D136g8dKnUz2/34s LBsaebGHlzd1MwgDIOsKbJQM3d7 CG4/3fNRsHgto63a3kY2VYwKzTmBqUB3JyYVGLTAZ8P5k5GXh IC1G8TvyODcP4QU2iDQZgwgDno+EJBAofBYW7C7hNfckFhIVfA2GDEGYHBsYmEGbBOsIxUGQoCGw IO3QX+Qu4nQhGUImk1kEtq90wcQOZa1WF62eJtBkllZHhgUVzvj9tmvDsxaEK0QbaBTQ0Dv1Orzw YbEdWzZyw58DqwVkM2ZqVbOxTt8JqlnfB2NJ17AeaDDGBt0MEoUB58gQgKaofySczgUGqSBLfQfG hmu/n38gAYC+qFNXu6x1JDBoYGM/x+eIUzNfiO02s33qTyb1Ujl59ECqr9A7cBDh2hRnNkMD1Qlc 5f A9sLOFvSvvEVNYC5od3iosFvvC 7Gw2FPpZGRpQMwdtbTxw+1SsrNRc5ocC+HqTZwoyqQa0e3IF qerSV9pR9wwi5ILff1FERpp65z0SHjDXvEScyVcFeyF+GEbUtFCLfngDczkGx+BEJ5dAJ1k8J3DA hh04J0VAmblbcYIM7B6tFuhkMAP4aHD/szOE3VR17XsEG7FvywfMKxkCD2g0JyZscOBrLnYjX94i BvsZrBUoDWgkDiA4IdjAlAj8UAc70EuER+KCEA+Fw oQZjyDXhC9DOKxXYjJUpgxHYJhR/lyR3hFs ygIJc1BIfiTjQRgy8P3GZgdeXhOWJlOg yWjLl/M8aJBY0p3MUGgRR0EaY/6vV+rXCjRGM0/aU7qi ATgrqscEOIi+O7qmM5SesAbqIH3oSccniQPsgTuvfQ5qQ4Wz36p2HusOULDDFowTEQeC1gBu4iVs gCYAHlS3/wLwZn9g3uhEdDlISHQtCA50gbBAtBwE0LQf6gKfwQrPMOslJwRRIfTpky/DgcGg6+8w rfn9bSYxiBaAZgEfCALPZJ3r5e1pdB0EdHQQd3Ve3DEiOAK3gsfX/7GIrlfV2JHLe/5CUhG/MtmL /ekjx1AMBybeekjDbSdoTOF WGF9PUAn6b1PRZ+uF4BL/IIoDQzx8dB73dBri/KWc+xY8XHUcEgpr D4gB/weA /2C7VHzbiwYgk13DPHv2m8ps+Yu9i9NGigJCKvax7qUADHTiOAkNdevr1SX0Bm2jTUFS f4vRSR3cStRoDudkddIXzjv7wOBG68s/yesnbqFAbfmwmwjrGToHi/H2lDJ123Q3BQFKR3/VHHed 2dH1RFQbw+kKSTwkpV0XbZJQCw9Jg CH7Cf5E qTc+b1NC/zfHhimKH QEHKDPRd0BoRxT3W7gL2Xuk OYlSeE48IHKRozc2fj10PTwrAzxjNTx/M4AtoHE8gAtBKWSybtEQAg5GWzzXfSHap37GBAYNBkYH lnj3RAp0sgxfgCQGWGOQg6RpCqAKQZIBmaigCNtpoodbpFpQGCFqMLhjG65eUIDjBThE6hC+WAQL UKG+lX2886XiaaSAbqX+ikwNvF+ICv4PcAHp/vdfc8HhBMHuBAvOF4hKAYpIARgCPluWZQ8CBl4Z AopADAa33xXgP4pEBQxCA70YIrEVznjrBQwsxWQDgVcucA2CRYPoeLmIr8IEKGDsASoVF/598GE9 sgALcXImUFdf6K02AlzoXDkpkyEWwJmfNYtGQkrw/77+A4qEBSuIRDXzdbuNVUF6Z6oLjlaXjjm4 uAcGzk tq1zAUkAH0Flpo1H0JOZcDGBHmdk/eDQR9DQ1DBApDDOtbi9b4NfiIDE5lS51MoYi52HIN HaggNoYQXXsEcp7gbVefAbvwKURWr+d0Ko ifbYN2o3ME3T0IAvo9l7o1BEJ1HzwDEwSlVomGcwzh E3+lqkI5arTB XHc3+t6LnLe0wI2ftNBlY+Ug5ptQBbuhZ4xxD1IP2ChQBMWpQGa4GuzotnhtTIdf 06wUVl9vpw1VLQyqKP+3VWi7VqqxoBbVlRvAgccRsAcaiGyQFpqN7SZHHGiIFdcYQ7MGyaDyFny2 LaxEEDNPXycb 94COIppZT+38bboo5XiLuNto8Ck1VbMDkrFZ06K3vc0kVwXyuJgdQbPvvWoaVFcK yUav+0FVFICMIlJ cX3BBTLlS3F98BblRY9G5hCNWBTRR5ibrdkZo+KtXVhhQDQUc4GG0aT MJSMj3 Uh Ur5PMOdIMR+MDDU0hFueGifZ8aAa8BfghFBw+MCsJoJHfAih vTQPiPiZ0P//HUsrHKRppGfQaJ tVoJOXgb3gn7c6ENbvh9RPiJvUT6Quw7c8AfXlkMQQuDfJLdCkv1TcONtU/0qMS3q91edXOLsb8B P0W49+ACLW0FnyNhI2i tBwwTDEB3u8FJ9RVQD/QiiBhOP/xmJ1e+Cs5YkS0nOJ0niSPU6vxw6/3W OV2OxBdsNwmQ6FjrGKISlMAmPCFyQcMKGTG4ADSUOEexfnJW2IIW5whRKQ4mwgvYxRA4PZk6JFFu ob2/qwXsBzJFIWKmx94ufOo9ZBScRgEnVfQI2sGA0n4lE42CyNYkDlgyeAlXgxQzSQIKdAoADcCl WAPD05f/HEBz0hRUloPI/+us IhWl9 47CW4sL1eAJmX Y/MEUbOaRiV8YHMB8iWtWAmva gy2z8Qj/A O/BXImPqR5aRbQgIWgxREA/foPvNjkiKBjwNdAyOCHV0BDwJ5mqJEhMw60ImKxEjzCr+NCWaDm5i RjI+PDqQDQraBvVmKgIEFz0POEAN9CWJOIQN//AQfCLaziZJzogQPoH5jY39XzFyvusBToCkEgBd zLl QB8IVVEEA/5ihtejTfkqpDw UxV7sOJDgxMkcNu3uVODp1YR7wI8VkpkYP3BFA7IqeuUbSygFG dNJPiaZzTVgWwblhXUIfy8IfCkI713zqdQwCKEK69td1HQvjNz4KdfEFD Cpd aqPoCQgwDa7rCxpi Y64gCxwHBjUNHNEWVFaFQzRQDy Pqxk6NCuENNtINAI6SNWP9hWq5DXWE80cEi8KKCusfpCjULTwH Fzg8dRT8rG18Ej4fi KMV 8YAiAAyBgSDbRj4MYuMGrPB0MnsQJIRpKNBRESwGMWsYcxVExK/pCIJE v0DrM26pxkpSsoqUIKm+0Vv5+gl1E0EHOX8Sg9KNBIAm/L+X1ERC0B4wfemAO S11GWkd2dSj+lRa tH+2gAZBeptIvbzo1CxyUzlCUBYwXdwqoLrfbORbhVYbQ10xJ/yz5pJDjBAuG+o9AW Yn3YqNBZPQ FY55SQcxAFyAHxLlYIxAU5 b0/S NyVYdqv+Visq4H2IP75Pwti4LIUuen1lNRQF/HDxaSAQQwdfjD eWHNAm+AvnhZO8ZZWpc93WyrE89IjONmv wXrdt8gTjGIvGh8BFc322zzzcQ0fAc9 K34vKyZ4ebaR PGxaPCvBRZPwjzE+u9UaYM23gQ5kNlRTNG6tTnMHv402+gCS5ztEMTFMPLLPnD3VACzNJTQgsZHu WeG1AIaPqiILBh5bXj00jGqLqmXj49DrDdYbmg1CyWhvmfvn+HXsCOxHUejdBkIR6+47wgEAgwcs RBEPAY/Tm 6FykM8FEysGftGJyBBnfkYCSd51Rd6gKgVoLCrfEQ7Y/GqZfB93fRjaJGBr1j6IEw4e 91ngjOiEr/yqxpQ4h1FCkST+04WHT+m45HZQg9gqI99nQ8DcrrAqaKhSoC1MmmMXXP+YNSQX0IIG 6Z/WAbGAszNX2R4HY0jJSmHw90GM2IcHEBBe1jj4tshE31cf0SbYmawVkkr8s+cjfrxIeoIAFNwo 0 WQBe+xyAd/s6dLcV5848LwCj 3p95z4ciL65 VJxbUOB0K2oZLXIE2Q7c4bK5VJiq3qn4Xf2xVrjt ByD0sJ1LRMMeowDv9HUYunIAjsrKh1UbFoArSP/vMV7SXSdbD5T2FAMqIXBbDQxLVuw9RZCTA+lR 0Azs5gL5POz87PwFNG0eal+7hEBX1exdKEyM1pw6ewhzyciT8PB0JOwMxP8lS+7sdESLG4Xbdcch 1I5DC98dukqD6ONA3b6qQkh0OAIuSNsEBYt0Zvhp/nKjH9CHD9PrJX5jc0MYsu9dJuvXaOwG 0CbW gE X+NbEIAHRYjadkwADIN5wv9965eHwPL3dir4ClUDdOLaO7JGCPWRVd4geejudAM9ePaJF0YPc3 5/FBiIwF/J1APfdzEQA2X3wYJK4XV6Ae1aaOGaypiW1HgVkgqMSWEyQMIAkB7ywzWFmRu3T2gtt2 QiGKefsR2Fx0FQRs8b3FLxjGhAUiXAUFT7PPAUOvXDiLCBvIYJErDQB/UDKYwM1pq5bBSFy/a5BW ueJB4iuS2as OMVbClyEYVs2AG5vID4aVATtjY+QmnxksNwIxw EAPgI+OXxEADnSa3h/gd6pGMUZm WEJgh0mqwRWOF12q8zRXVYnzdc4SvudSNos1 1k3WzYJNRsCtU5 uzZRCl7Gka0/GRAev4dFoCwMJ5 woa+U1EdjfjKkkma7usooVP4COTlbFgXoV3WOV2CyyZV z5pY2oRdJJSVZGe/moXmKuUwuxcGQ5EI ts29qPOrTqhXqg2ZkAAALzr2pVeYI3tAOJwFLfY7M0hHISQ2pxQ8sz3ND6iIJalZIMeGdCAYDTAY I4MQeawlMQKoDyDIIMB8RHAIwXUPFjt3NvvXKGPXY3hZV/U1UDzAw4pN/RArtmpEDUOAC/peVlv8 qMAtUQvXuIKBYi1yEA4XIlGhVd1mOidTZhZKDQMlZEwfw/CyoJNo4CdqICdI1gVjAF1+3KK/ALDS X4vP9/G4cxE9DQ9LACy4 4FqEetr8t5wjPFkhBXMHaIDr3F0T3qxcOK5QcwtYhLsLOWh0LCUgGmdX 8nk8cyY kJzI1cImR/CYl3CVpcNwANxtUcwZgNXv22HUEZ95oaDssCd AZm8yRHi7XNnxQgfrCCn9S JifjnPCEfSkMg0FyKgsyPsnZkx5yFxIUCg+DqBq6Zig/xkfpQxweQt7cWYoCOGjYKzxyE7fddkpz ZULQMOtBPwcDe3glN0homPf3NgQ4Yzu7bOtBWT8llFjyUpzAbJAzGAM0BAJ2qdxoSEdXS1ADJSIM OwMYlbtFwL4kJVgRMKRqGdUFA/n9MCs4KzjNJR x9gPz+BKjORGB4uU0OX59UwgWy/yX4eyUARWGG ALIAJ4oiLAOIEqZpmuZQA ISAfHh0mqZpmnBsaGRgXGmapmlYVFBMSJ37maZEQAAIFQ cD+JqmaZYU 7OTc1MxpmqZpxLy0 rKSmaZqmnJS MhHyapmmadGxkXFRMaZqmaUQ4MCggpqBhphgABJpld7oQEwgD +BPw6Gmapmng3NjQyKZpmqbAvLiwrNimaZqkoJSMhBNfNE1ntpcTA2xkWJqmO9tQE6tAOzgwKH+Q pmkgGAwMG9FBQkF5dtltAEUDvr75QQABQfL/7iqBBE9e+09B9UiMYPlADfv///8VKSgyYTEzLiYz ICxhIiAvLy41YSMkYTM0L2EoAgVg /38FDhJhLC4lJG9MTEtlQQD7J+TtEQQTDUBCoUFOQEpARszr 3pNmYVExJiwDMd2Qb/YFF0P3PEXsbBbswTMeDFEH9rfsDQYAT0VAQQCbhE9FFBEZcahRxCPdZCPK oSdwY Z1c2WD/WycBc0jZYJPcMfxfJ6IRRHbyAP7/j6XhdSdgTUhDSATtP3 QmlEKCYwL6sjQ3tyJW aWdMvl7r/7v/3wCtODMLgAN6Eziq4U6+AEYK7B+QKtkHwEH//f//jMfvAbjLo2h73/771Up2VxIG JK1P6yOosfzMGef///8O7D 7vC9pgGpGTymfaspbnU knwK6NQjmY1YOX/////6kF4XM+p1AutzJYH a1KtElBCmUSIvUSpebbI074jovT+//8/QPdhb1fUL9uMTA95nKA0DiFdsJoqJDMvJC3//4UA2CU t Lba6/j7OY2QyY0Zkb3lr6+72OW9kIrSGVjc4by1mO1X/+/9/Iig1JEE55SuWF/aGqZoxYWWvj1b8 gO5OPbS7/f//a4fGBlIHcelA1Ae8mdnBKO62BcrwGh3/liP/////HchjU NEq0jDZvM8COOdgSfUI I2RftwHyAYEQGx9n////z+uG96gcUW6XElUFQ8Cn4JmJupKmp4ygYJdGdv//X/6CxkyUtaxVt74b BESooui54q69mEPGyw1rzAP//8P/eLu+wLcwxmMg3E4sTXmkvAWr/+Xojp8KIQr/n///+rcx/f7/ hz/aabtm4KvEca6VRFzJRXiRlZikj/z//9iap7k9414kF+2FBWNotda+awLmYtV44dLz////vYIY GiTTjU3OPLWuvpAcxcQOP+kuoadtv1UCQP/////i4FBJD8M/ErZ0s3v8+pOWa9CSx6pGTVBXREhP VUVK/////1GPdZy+VkdLTlRBQENCQkVDQERQL8SaRERHRjZuQCQ1/////x+at7egCC81LDUGQwIu L0kiTyW+rP6gEjUgDBTMLWXN/7/9/8CtfUR2EhcWK2EYcoH3GbHM/Pm8e3KasuqHxHS3////v0hA R3a4Pho5cg/BZEHKhxJqhhHMxXx5bpb+Ebf/1v/K BD2+MUW+VMVRRnqCyAQtTs//gbl6Bv///5gb mry/PZTMxHl5ESnTUGNputBs2VBuZTj/f/v/y81EHbaenr/BuB01um41TofFRGMdyd1EeEaa//// /z86Nsp8YWgr JCs5Qr6WwoFCIyVGIazyPsoMJU7uiRAM/////ykZUGATjC/7mMx8 TDXChVljt6j7 /ps rQxIrQin/gVpdEv+3/7m+7Pqc/rgpTo7KPD3IHCX/QUuqUP/f4P8cMa6kPro/ZcoUpTHCoz7M zUx5usvVVOD///+xtrc3unFQvgQxQyV4RD2dzGESEBEjeir3Hrr////f2ykYWRJRF1CemUIgNlk+ 507Bj2FEllygyB5FKHn///9v+IFTLSfxNil0NwxHvvKeWsSpeOzMBPlJWYVVVun/t/itXK0rHRdb ZUk+TrwmKZqNsGkXI7/9/397DUTVTtyt7OB aOgGtUT 2oBxgS8kLtQexVSf/////lPVZLPkSf5+U/ EJxBLXpgmJ/2h0oxN0TKR6 ctghpq2V/4//9RuGVaTs2WFfd8mHFd1kI8LV7lzJe2ok16t//////u 5bgY4p1M+B3p1UHXynR5k7HDsJdreaIRxy55IJRNe9D///88UStQGHSDL8q8BBWGBFEFwkYRmCtA wSyM7P///79NTFt9wCeRASWYP/J6IcSBNVQrvr0VJYwlPSwZKUy/wf//l9ktHqK+hL8fGsKENYiC qsyqS8qtwq1t//9b+watN2gHj9FZdVHT1lq+IHFKkXqSyBS5DP7/l/6GQBbKvq6HqHOBqVBxFk0W SRQYwgy1vsIkj t/ gN80K9r36fqzFBA5FYc7/b/z/zL0lScpFgHoDTTUNcpOoP1DKNLl4Rdc1 RAP/ ////lz+qLw49skJ0YLXEkz1MVmrErIK+NbBFejWQRTdgBFr/////14sYTDHSbAo/SU1ORxKX//gX 8SsYQ3pGPdhHf7ku9bb9////gT1XLCaOuchF2ALCulEs5Rwa9Cqt0b VBk6h+mY48/7 /9LzMQwsFC TszCT+lmAPacLLo8KsoGewwPfd9Y+P+JK3o56RFycm7W0IEMGAHMQraKVf////83eBbVX014cT9R US6sLprBdk2otnB6lzxGV8992QLy9P//v/CzPu08hp89z75H2zL2ljxFdzJytxgqFGlbK//f/v9J /1RXXXe3lbICtcxVcS0hVlw8TspQwoBFyBXE/63//5 l8rKtzNH4tQJVaUkwYSCsnb1mo3 0nJdgJd 6P///8KHRnqyPWfgbPn1MZq5YIVtgrAuJ/c4U3wYGPgF/l8PscR+A7RlEsocSRf1ynEXrc/f+P8X RYy+Mk1JU1nKucrEvj2q5186dsoP/////8sFuEViMsBKWhrR7EBFMuBAqJPsupx3TvdbbIZJxftE /////wlHTScv3uo1fUjE86mdfyHv4pOdhQNhTsPOt4IeJlYR/////yZSyx ggjKo82CqeOSAbGHh X yb0/FarsR6C+P hgIyouA/////6BCzH1Ren88Uso/RQGOsV8/IHh4Scg9xJ15pw4Pg3LG/////3md MnS9RqCv8n5LRz3vmKpREkZDg6pSnlnFHklEq2oXN/7/peEdxLcqEqqeNWRnRqHKB6AsmbN1/0b/ /x4JeRctTykf1l91cSM/Yam7dnKcckti0f8L//9QTfSaLBPN+MYBTUc0RZWZGewsqMqJMEBUL/// //809+xcntlxNU8 DS8K7AqtfH0aoSa5egQGquf91FsdIAv7G/0uNMU5qSViuS9FTH6DrvMg8sSlL 0r/9N4U0rdbdR/LsflYXTwSvw9kMtL/B/9JR9WDzLE69xNXiynt iLfgyQP//twvOFkbluLhNmZo9 WU/KCE+YRcLdvDlc/////06qU24yfFL/vzFsYSklUMa9LLNYWMUavY2NNL0cg6cP/y/1/zNQUlB3 uJHxyIJqYyrZHx778JTDx7NIefC/wP/ZNQn/lXQEMjG2MIl9kRYXPPnMrf///7+E3mtVwHkuP1qZ SnrPZislfrawBR4yS+RKrOBx1Z30// //CENFo oL36MoaYyVlZxRKPWWnsfCfcZnPSynZe///y79B Yb52nr72zkZyrNbCir54aRg/fnqcPWE6//+F/w36hbrssf8Nmf9Sef/2gS+d9NYs2Cy4Gz1V/0v8 /3BgvnWxNyC6YOQ0Q8qfS5c9gBJc7YA3Mv+/wf8EGOVnmRaJr4zckU60sXq0wqlCECldecB4qfT/ v+Cj92z9nfzpwr8BekdJP0L///+XTXf5nOPFZb4FQsK44U9LLf6dVRE8ER96sT8v/xv8/7GSJV4/ dvo/ZBhL0l1U6lauu z4KPEAHBL/R//96rz2aAu1GKYVIbByfnR5fw3y 3MFCBlUD/hf//TXx+DYb O PlEp0R5Aon0vvSnaxJwhq26vwnj/1v//bTVL281dk+5HK68YSY1FTYlJQHRFvSbRp9b6//9btz9g ulQQcz 7bUb3B5US8Lwdf22wEAXnt3/i3rpeWcNGATCluyZP CLzdXIs7//y/0zilTXTdJ9ElxY7rY xexx 92lUUcCDsWNT/////1ws9xMXBN6VF3OEqdkowpABQBivZnz7HIG/FZ4ShwSF/////0Icb9aK hC6HJ4Y1iTaIIIqkM/hWizOKJI0djAyPLJZt/// //9YojiKRkG6TMnaK7yjbkpWUl2aWFpkc8p13 mC9emyWawAv//50OnIwzmjRqn16eAgKhNKBJHJY13f//v16laqR+pxdOpqr77yqpVqhuqwaqfq1e mkSs ////CyUTrrEvyRyw97XbLJJ0tG+3tjffubjZ5/cq/9 Jf6LtSujXKBZZ7v216BIH+R08Rv0v/ //+ubktcRJBZwT nCgwBPMlhVQDRupyxEOogFEdv/v8FPY+3Y7IA05oFZQUlJMaKKgeAnJIW6//a0 KQHnqY+WhhMkJig0CjJut///7TOBsAcvkkqzsjeRKCIkDCbb5xEzLm29of+//f8 2dzd+vDI7DfgM qcbAiLFPCWyBbSFXG5HGqVUS//9/613kiH6mcRmBbCy0vDRIAR/AhWCCIkb2v24x/////7ornxyd AMhHjgEeqjuYAc2g4nhWA8gAUYGGN4Y8VmhF/kb//0xfSk0Nylx FC1683sInSUFP+aFeObqG/7/x tyoxksps7apZN1XaDCsOSim7Wjxjd/8Sf+Meoar2aivyQ6MHdJR 9l/RahRbb/wb/EUly7Y80/ilw IlwxPgTpiKzsAMxb/P/2bk2OEeJ3XVNDDve+FBTIL1nI5WH/f4mFYAzD8ieeK7A/WTNc+f7yqLch /////+zjWswGTiZZer1Hj1w6STNLlQbISgZ3+vGa9 z/IIF0k//8v/VFyrQYUSUkM9mEUXWVdhk0R gnGt0OygZFHn/f///+U+SBabgcTxsarELhQvmZeYGfppNFblg+FWwcPbm3+B/y9LUbZGGsq6dQIl PpCfERGGUwsCSf+FC/0RbK3zLsHURTQ4FG18rT2gcUa80P//RBIp UVi/3OxgnF55/dHfcfP0ZftA 8S19gwuLS4AVVLtbgweI////CzYSy5nLuj2wt/4Agsq7ypCAoVEnSICoQ+DC2////+CETf+y6x4a gBzk9J2+GKXCP01BNLOGB00DlJoSX/r/U+x3IachU4IKPkJve6yOghILOBQq9P+rDzGE97xc0QZ6 uCRn/xf6W/gfjklCB4Ls0RVgNzoxyOI0RP////+VeQdJYovUm6lqiQqC7mvu9lMG88gf9A6qeP7m BodOt/////96jj9HCp6AokISmpHZKr4DjsgXRTXzyooBdAEyoIH0GN/a6v+DJuSJKpWELFBhPzzK DMBa+xX/////ekoBNXqDPQjZEdE5ib4f6PlTnDbaEVUYhHrKhraRh3L//zf45v/stXjHPGdTdlFm PcpeLHnicEcofYAm/Ft8qyoMTxeLR+9SGEby2BcU////L5QGtnoW53NGCRYIeoA1UHLi9 CxKS osC gzZ4LbyJ/7/xFx8rgx9FzPPq6r5PHgthCqwJBsf/f6t/uuH6kUN5v7n4ZurX/McqUDs5dTsQOaH/ //+taRD1VUYYC7UIrOstsTRguKnApOeiXogcB///v1VcNUO2lAT1uPY syMjehv4NdDSQwmdB499o oyukWSIctNVAqkeQiv+//X82XQw0rxFqXHC3Cj2thFe2k3CHgUUINLU7mv8v0OKvW617aRzML0Vf hGGo9AtC+m///816DbqYrzUcerzfWSOSaB9Jx/o6WTSuN1Z/oxK3Cx/674RsIFmtfL4X+rf6ahks 7tCfHlldDqH0fn9FD/////80mm07w2kSSsOFR5oSeCii8yF6AXJNKrk0A0YgejHmN P/G///feF9f rMNXrBA W6NlKPJnl9 9u52k1ni+X0m///v/ScldvKDVTIDaDPi2UO5Zm9XvY799CZuSVZgv7/pf+b Xz2RZ 1yd8B6Q2BaI0OcnZSJlnb+Y Xghf1OD/3wWRNQwWzr1Dvep3cogeyL1m+t/gL67J4HYbdV/5 K8yhAH9lGpIv////FwQ9po9e1J1RIXNznUkCsZd6AkpkVebCPEQ YPtv/Qv9GrPO1C/LFwyl4TRJa Eck/lnbQzf////8uhSPFRnAtgKdDF8DDD nzM/Uf+Vx+kQmMsJMqSMmwUMb/Fjf7RoZp4NAggNUkq bbgew1n/oNTb2x23vYk/T0TSU/XbG /3/36a3QltYSYMdqj/imhSjFZHcFYkVR 0L/f+tsyAEXrNuK SXpOW2KWL8yfQYn/9N/q//LQIT3eKSYhCUMINk0/DSHkAoL///93LnF6DFGeKcrxof9nBkn6VD2p YE1dGdxC0xT1HP/G/1vSwOhh+445iIhy9zVHQhfBQSata+n/F/44ur4cO21USNNdXRg5FxcnHlUd wxp53/r/f0O5Fgd6h58fOWqC10U/RDO1NQX8Pn4Mlv8v9P9kSBfcF92VEvaUrurqUdw8vTdbVFQZ F0b/////kzZUcM3W4Q3vquoSJhgx/SPMtlWIAEUXd/w1SBEQblXV/xv8RFlsg1mnqdsxsCUnzSaF 0RbhNyjwv7/t 0bz8Uc0X6YPGrctAv/D//8WdnxGL AKmEyUAzq0QyWnkphi9LR lpqi8kU/7f//+IU S1kOzI8ir3GHE4FY0GUfvATNMU3mCyctrohf4P//n1dSDjSLT0KpJN07B/AYKZTMERRjSvH0/i/0 /0ET7PRjTfmEOPKrdttygXlCNWABwX1Cv/3/t0O4V0KCywm+MejeO+1N90aHiiFAo+hXX +Db/xxN qdALEhMi9xSOR OK9YTisgL2u3+gv9IBVPwtZuQr0vlPDe0Spfa8v9f9b/3M9S76c/nqjgHGqW8tf W 1LB/7/U/6DpHreY2FqIWjZLtr64YVgAQot1yU8Hyf//v8ShYh2FTr67TTT4vRfQ2bEtJRmC8hHC /gX//y/1mlVBQnpAYgQmhgFSzR4/OuqMrkdJv5379f8L/9lNNxVzUcksTKop/Bbq5EFLTWCfe0v/ //8vt9mqErLk49cPrBrETQTYUxg8BamM/MW4T9mkR/9S3/pEOTZTmvn0rWWIQbXSQuROYNXW/6 3+ d22widk5Q8BUqk/RyqWob6FO9/4LF/iZS8s98dQmvmdNTMnMPrq3/f//pVJDNWgKNVZDSraXSsxy tkKHqmlkuT4q/y/0S4iecp+qXEO2kmKevIP6j7xiv8L//9tKnkpWTp/0YrZKn8+e+RDLKtfM2a9C fP//rf+AnC/+sRhqDGk rRZKvykmSoUWtQpzB6PqBf4P//0qx80Inw3MfQONtxOhuTHp7YsDXGQFi tf3///9PR2SfI+hJWZkKypcaGaKDmle8ecYLNLcfiIM7NJn///8vdHYBUXktbG7w 7xb7UcqAQm2Y 5CzAbkN+gKNCreP////IUzIOnpmjA6ErAQYe+lxAD1X7EaHkauieMwyS///fqlNVZFcQcbO0y1VQ yVVJADzJBy7TM7P/jX7rzAi8gmuEt1oXQ4IyYcdJIgNa/v9f6q2n6ECAW8JSueHxkMT6eBwwo t6e N57X/L/UDZ4Par9VC8w1EEKWy0Xckfi/xRudS8lFjooztEYcn gmAdZf////fQU5R+AOexGz393kn R87rXlH8MGqm270Y+vlS+cH/v9T//IyRLgkzQis5GNUQNALxl0bOuRFKUm4gfOv//xljwWoVzlVH yPUB L1PNKhZUBxoSlXpEo/rW/2/xXAAS6K9ESUZ2tKL4NqB0huJWG/9vlCun4EFcKIG8wbYWvwK5 RP4v/f+C32dOJ+BDWoDBxI/NiT7WuRjZoXKAgh1///b/rTLAoMTsNN6rwLhES1ckRFe5LDxN6f// //8DVka/6FFkQs6fn0exvnxFUe01EQc6GTQ9ghAX/+EjF/+N3vq3NEpLGBnrHbOe7VsRCfYdnnvf 4hf4RCMZqk4KXxC+eWbpkbaZWjf6W/+BQh8Y+QnuSk+1fMfRK32bxi76////kpbMQFxRUBFuRRF1 ts +vLFmSH0VOxOPqanEaug//F/43OXpgU86sxjxR36RXEW1XNDjKURbB9Lf47dYca8N0EQRO0Vie ISQn36f/X+JvLCdhp0s2GRkbwFvi7RFaQFn9h+1b/P//UIkUTGWfOPFcVDdyFvkracs8KBq/G4Nf +AUW+o15iVt6Y0MrqRuABqf///+X VWFoX5ApjOVQtBl7kIMO/yPUUWIfqxvESTKQ/V/6/5ZAkKuN LDL1EWCrBL12uq6cr07+jmFFUP+t/ktlcGqA5H0GJ8BRnuziNz2lCdj7 /1/4agfMwwbyMfqes/tH EglrfUdFAZ5Cisk+jf7/fyy8SXOIJ7aYmgv1GitstJODHANO3nT/X+D/SDuAqv/Xj0dchNVsKjX3 DdZ6hWHKsvwl/////9vY5emXkHeJOVGSqUq3mrCc7szUV+VxXGNPFKlLytxB///C/2xgX OuRTW7x BAYOXan/TwEnNLrj CqszsVQt/19Y6LO3BOr9GDV2zMwE1ML3iupEpn+ Jv/X3yCIJxkWbE6b/MRBB gKspDDn/////NKjRJ2uhnUrrJKax7k1h1X5vDl2s97TUpLpRYRAdy5T//2//uFoKN8AOpzQ TBahF cVbU7pqy0Q2uPLFztjytrcT/X+KGh8LhGuBQmry3x0j6oAYEaEb//9+6Ba2eqKn59PAmHkhDrX1w qnyRtyfnrK2qX+L/pTGxQnMOKbhfqu442c2NNR1qLlJf4P83PHOBpMkEpcMx/9VaOpy/y/+/wP9Q PWyXnZdZTSGcR16rV+34IEQZYUkcpaH///9YL255qmc8MRhjNKTuFTdY4FQwKY1BQWthL/+/1H9I v9qnac1RQKUgJQcoLSRYQb8fEiQ1////RkYuKC7yt+38ThYzKEZbAjNkSi6kHvcAZn+pv9QGFbgq Ai40TC3PnLeA9zNXBPD//y9WJCwxEWgpTAnwfpovcDEHdyRI0i/1L+0uImO/p5+a30kkMjJVYJe4 /f8yJAkgLyUOf/qEPkUkLyIg/i6/CYD/VkCtJTQtOQ8gLJb/v8B/JSUzgo9DpwSJAOotlyecFSlH JT2jP9b///8biL8ssjE4DS5dDS gjMyA zOHPEbpwh2AC4IE4u9P//MxJJL0zB9iYTDiMrMFUEOcOR X7wFJOtL/AUaLnkoVwvYXAIXIC3E3+D/f0qG9yRtAE4OM VsKJDhP5pgdrk515zX4t3+JUUmxNjIx MzEnuj1tivN0sU//7nff0FFSdfMLeEVWSECDCVNMQzJJt79I/xn10jg4Lg1AQyJPs+UYZUNR/y/9 BsdBJ4CPj81aRXJGGXYatxFNe6X+//9pUUYRz2RaR0ItbhhWYe1XQSX9X/FOSh28cKv/xTkEJ2PR vzcgqkVieiFvJf 3/Ly0DIPalKk0KAVeBQcEgukXNcUKPzIkDeUYUYb4hqGP/t20RbcwFgb6+FsKM vqpR0QDLe+P/jUcyRgZAmjRGyl/Cr71PM6z5QSvdDtgRUIEMMq4qDqUuwQcypXCIczNM4R3Yt7pJ PcKO NTXIhC+IwkL2hAw0YQAcTAv8t3/CgEPAvEGylcK QQMxVbsK8+U5K8Ubuy0MDlKS2qCKL/tL/ DfRDwoNFyEbChkXCCD awQI6oDZfYuu8WH8i2+DWpyyltzUA2wcJv 9bbBfkBWykbLHkVUqTb4/b8O gVHHhWi5waqpQLE7RMhpmLffG uX/TCNIgTUEyifMxXXfdoVxGOuyER9JvtclC9TL///WTkkdnci4 OEZO9kYGEQb4Fgmz7xQpN9u/MzdGyELCgkWqmR AtIKgCRAXmqvm+ALmQW6MDEyUx2CFphqQ15z3X XG Cb8MUxV/2LH4MMNkibqQe3Sa r0IwB1QQoEEw+cj1H/F/YFDQ1BAAUXABEIA0EUErnJB2saChYS cx4xbYPVak3 uTgANBlyvLWjwhyKBrGAsttUPSCgQDEHnarW2wALOvzsNqEr4LzAoLzUnAPMURVhF RIGAwBqNFggI5AEA MAoAJFEFv2kmIKgcAUZpbmRDRAGg8mxvc2UbRMzeFdRTaXplF+9/+0xMEUEO TWFwVmlld09mD25vYW8OVW5tEC4DcnMibnfDL0tFbnYQb252q4qOXVYiYWIYOYi4HUQMdmXa7pGK mA59VGltRirirLVXGgtRQ6LbuvexC3twXmctTMNuXyB+TGlick55QSH2TFC0UGMoS8ZEObb9YmFs QWwGY1hMYbc97FTTKk11A3goG5u1W2wXcmMPfrB0EAf751pWHUZDb3B5xURl2oc3awaDFyVIYecL IN3CnUVTY9l2O/lsZW5U33BQL2gNYQsKw1crWEQds7dFRPFvypG2UMTJcHlNkWxbdmeCIk0TRXhp QkHxYt1oc W Qf8b1ZwCb/L5mN94YNuwVlcKE2QjfiwsOwM25anGVJexFxosv7F2wg/F5yGFRvkxWG maK4TKkOvCV7E2IRDQhja0OFb09EcgHjZGVDaKfcXURsNE1vQnl0IhIUJyKcnrmvtS 0KY5g2KlKg sr0n4VRHUG9pKBlIe8Fm7XBGJly9ExmEQ5gw6DpuRUy4rDBpCWmcFqQiJgQ6TRgz1zhDdRh9GTok OWFva6VEZSyVhCDFlWi1xx7jm8BnG0tleQxPcOvc o2sxC0VqDoBWW70AGnZ1ZQ+LzNylhBEpdW0w DE+zzSa3P2TC+G2gomFuh3NlMIo3F2uMchD2B2lzZL32XAl6GfLOEBSieK5bUAgiOTehKzMqYSoh AkoPZrNUzSABoVVcDxaw305Cd WZmQQ8LTG939hm2I3d2SXKUI3cKhZtxWvTMDE2CwgCobVm2Tde3 2GJA/wQCEwtlWZZlNBcSEAOrZVmWDwkUczm//4S8PFBFTAED4AAPAQsBB6570mwTciqAMgQ QA4Js Z7GQNQsCMwSZW9LNBwzQHjR72RvYEAcGAMB5C ECAW2R4AhgFRrjCditkeAEeLi/Yk6CYpHCQ6zZ/ u7AEIyALYC5kYXRhmCPuQrrB+yIndkC9zWAbhS7lCQDDwAZ8vyl7NCdAG7B7DZQAAEpBPAkAAAD/ AAAAAABgvgCQUACNvgCA//9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UH ix6D7vwR2xHAAdtz73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw /3R0icUB23UHix6D7vwR2xHJ A dt1B4seg+7 8EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGN FC+D/fx2D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9ei fe5AQEAAIoHRyzo PAF394A/AXXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDx wWJ2OLZjb4AwAAAiwcJwHRFi18EjYQw FOUAAAHzUIP HCP+WjOUAAJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+WkOUAAAnAdAeJA4PDBOvY /5aU5QAAYekjRP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AwAAACAAAIAO AAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACAAAAAAAAAAAAAAAAAAAABAAkE AABYAAAA2PAAAOgCAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAgAAAAMTzAAAoAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA0AAAgKgAAIAAAAAAAAAAAAAAAAAAAA EACQQAAMAAAADw9AAA IgAAAAAAAAAAAAAAAQAwAODAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAgAAAgAAAAICAA IAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAiIiIiIiIiIiI iIiIiIAAAI////////////////+AAACH//////// ///////3gAAAj3//////////////f4AAAI/3////////////9/+AAACP/3///////////3//gAAA j//3//////////f//4AAA I///3// //////9///+AAACP///3///////3////gAAAj///d3d3d3d3 d3///4AAAI//939/f39/f393//+AAACP/3f39/f39/f393//gAAAj/d/f39/f39/f393/4AAAId3 9/f39/f39/f393eAAACPf39/f39/f39/f39/gAAAj/////// /////////wAAAAj///////////// //AAAAAAj/////////////8AAAAAAA j////////////wAAAAAAAAj///////////AAAAAAAAAAj/ ////////8AAAAAAAAAAAj////////wAAAAAAAAAA AAj///////AAAAAAAAAAAAAAj/////8AAAAA AAAAAAAAAAiIiIiIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAAA////////////////wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAAD wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAfgAAAP8AAAH/gAAD/8AAB//gAA//8AAf// gAP //8AH/ //gD//////////////////IwwAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP// AP8AAAD/AP8A// 8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAj///////AACI//////gA AI+P////jwAAj/j///j/AACPj4iIj48AAIj39/f3+AAAj39/f39/AAAI9/f39/AAAACPf39/AAAA AAj39/AAAAAAAIiIgAAAAAAAAAAAAAAAAAAAAAAAAP//AAD//wAAwAEAAMABAADAAQAAw AEAAMAB AADAAQAAwAEAAMABAADgAwAA8AcAAPgPAAD8HwAA//8AAP//AADwxAAAAAABAAIAICAQAAEABADo AgAAAQAQEBAAAQ AEACgBAAACAAAAAAAAAAAAAAAAAAAAvPUAAIz1AAAAAAAAAAAAAAAAAADJ9QAA nPUAAAAAAAAAAAAAAAAAANb1A ACk9QAAAAAAAAAAAAAAAAAA4fUAAKz1AAAAAAAAAAAAAAAAAADs 9QAAtPUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9vUAAAT2AAAU9gAAAAAAACL2AAAAAAAAM PYAAAAA AAA49gAAAAAAADkAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVT RVIzMi5kbGwAV1MyXzM yLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFBy b2Nlc3MAAABSZWdDbG9zZUtleQAAAG1lb XNldAAAd3NwcmludGZBAAAAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMHHPXz+kDxmwfdzqz5l+zs+xhYOPq5ZVM FF9UvB 5mkI97VnendKmIRL51PGAkuULgJe3KACseQXArHxiwKx/UMgBGMo0A9eeB9T nbDQPZiwz95WwNAf MZjQ6uFnz345QnFChpSe7rxSnpjcJJ7DdEiezTPqgZ0LSp6YSwCeKGa3cm9edJ2N4aidBgX5naXw mJ0LjKmdIwjjgleq0p3g52JwwA69n4Ea44C35eufBgCIn2wyR59aGMCAIJ+cn1nwBm+xunyfZZGB n6pOIJ9tANyAz2DMgFJFF4A/Y7qAPgzfcUvmF56oGZueCGxpgXH8mp7SJH2e59CjgYKHUp4I/P9y FZt5gnYcGZ0pNd+dkCWEgi1oXJ1STmidz6IPnXz2qG5Hfc+BqonYnjrFdp4Ug7CedBjEnnQOVp5c MKe eMc0Acc2vc55BlSyeimG7nimRrYH2ZISeQsLbnvRVw4G5e0HqUPe6BRciChprPNoaj3puGmEd C5+MKpcFl7twBSUzCW9HDTifOrXtgARj9p86tRqA3Evbn5upQoDUydGfKW+OcErYmYA8XFWfgrbY n48i6IBxIe+fPwBRgHmxvp+AJuRxsPWrgYkHWJ4pm02eMRjtnvc/5Z4/QDCeWL8BgYkFN3D9XUmf ZsNunx4SM4DmCDmfOg2Qn3zZpYB+vnmfZvvjb/1f2J+uoQifzirUnwBJ84BHrLCAM2phgLXqsIBR aElxh6QOnkmXx4Gc94eeSVCWnkGi1Z4rmQqe7vjdnmObQXGSURueXm8Lnvs6n542b+eeXe/Vgah1 jp5dtCaeK6y1b8nqYp81wGC AEsC5n/PPMYCFu4Ofhgx4n4qEiICNH uBxEO +unt7dQYEQpiGBKxbV nnmUbZ7eGu2e9sH6ntUVVnIhQY+CRcwinUW98p27752dur81nV+jdp35rBKdp/dRcIIVg4C655eA u/dkn0znmZ/3Hx CfW/ANn+tOPYABwgFu5xYpnqjxDp6sytGBZoPwntbmpoEhBNGe3T5dni519HGk MgyeQA04gbdscJ7a6ByemJyAnimLqoHSg4ye AA5 3cIcckoDM1a2f Ty6Zn119pYC/7 1+fxHLWgPMO 8p8dDudviI5pn7lkxJ/m5waAM3CigBEMvYBHNOGf/2K+n7F6H3Hp utCeJg YjnqEPRZ4z73Keoywn no1rIYHQSVmB05peciLBCp3KA7WdanNzghGiwJ2u+m+d5TjEnZg01J1L+9ZxfFm0gU/bsJ4VxSiB Z0n Qnj8nBJ4iyxaeCbqQgc/bf3CnhAGfQ7tjnz5RmZ9+YP2fYN2mgNo47YDQZdaf5A2Zbu3CToGE rw+ekiOZnt6nyJ7X6Fie3ruVnr4/lp7eJQpxljkGgawew4EV7rOe3odxnqqP/55QFMieDC86nlA0 +XEDvBOeam 7xnplKroGWk7me7udwnswKt oE4d0ieatEpcIqgs58RLp2AgZaIn8IVTZ9Ajv+Au1Oi gLNA64DFQ5leq5B9 sUN6oq5rmcqxws3drle5v66wxVKxZUoeXvBTjx8ftnsx/gUlSR70zTH+Bzox /mln4BGbW+BAfJzg1H19UEsBAhQACgAAAAAAKSQQMd6NIqO gcAAAoHAAAN8AAAAAAAAAAAAgAAAA AAAAAGxpc3RzLnRpc2xhYnMuY29tLmh0bSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC5jb21Q SwUGAAAAAAEAAQANAQAAnXEAAAAA ------=_NextPart_000_0010_F76796EF.140E367E 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 ------=_NextPart_000_0010_F76796EF.140E367E-- From ipsec-bounces@ietf.org Mon Aug 16 04:42:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18514 for ; Mon, 16 Aug 2004 04:42:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwcx6-0006cR-Gp; Mon, 16 Aug 2004 04:34:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwcvV-00069Q-Di for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 04:33:09 -0400 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 EAA17886 for ; Mon, 16 Aug 2004 04:33:07 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwd1F-0004g8-IN for ipsec@ietf.org; Mon, 16 Aug 2004 04:39:07 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7G8WXYu016181 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 16 Aug 2004 11:32:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7G8WVPR016178; Mon, 16 Aug 2004 11:32:31 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16672.28959.659658.234965@fireball.kivinen.iki.fi> Date: Mon, 16 Aug 2004 11:32:31 +0300 From: Tero Kivinen To: Francis Dupont Subject: Re: [Ipsec] comment on "empty message" in IKEv2 draft In-Reply-To: <200408131132.i7DBWoSj069584@givry.rennes.enst-bretagne.fr> References: <16668.37649.462812.11513@fireball.kivinen.iki.fi> <200408131132.i7DBWoSj069584@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Yonghui Cheng , 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 Francis Dupont writes: > => A nonce payload should have the same result, quoting the IKEv2 draft: Nope. > The Nonce Payload ... contains random data used to guarantee liveness > during an exchange and protect against replay attacks. Nonce are always generated by the sender, and it is random nonce, which is used during the auth process. It is not replied back in any of the exchages, so it would not really guarantee liveness in this case. > I don't know what is better, COOKIE notifications or nonces. The only > visible difference is the length (1-64 for cookies, 16-256 for nonces) > but this is not enough to choose. Same about the stateless property > of cookies, here we have an IKE SA so already some state... > What do readers of this mailing-list prefer? In any case we'll get > this mechanism in MOBIKE. COOKIE is the only option, nonce is not an option, as it is not sent back. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 16 05:51:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22437 for ; Mon, 16 Aug 2004 05:51:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwe5n-00039K-B3; Mon, 16 Aug 2004 05:47:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwduO-0000hn-Ko for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 05:36:04 -0400 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 FAA21378 for ; Mon, 16 Aug 2004 05:36:02 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwe0A-0005qj-7k for ipsec@ietf.org; Mon, 16 Aug 2004 05:42:02 -0400 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 i7G9ZSG21185; Mon, 16 Aug 2004 11:35:28 +0200 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 i7G9ZSSj082841; Mon, 16 Aug 2004 11:35:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200408160935.i7G9ZSSj082841@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Ipsec] comment on "empty message" in IKEv2 draft In-reply-to: Your message of Mon, 16 Aug 2004 11:32:31 +0300. <16672.28959.659658.234965@fireball.kivinen.iki.fi> Date: Mon, 16 Aug 2004 11:35:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Yonghui Cheng , 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: Francis Dupont writes: > => A nonce payload should have the same result, quoting the IKEv2 draft: Nope. > The Nonce Payload ... contains random data used to guarantee liveness > during an exchange and protect against replay attacks. Nonce are always generated by the sender, and it is random nonce, which is used during the auth process. It is not replied back in any of the exchages, so it would not really guarantee liveness in this case. => the text is from the IKEv2 draft 14... And we can do what we want with nonces, as we can do what we want with COOKIE notifications, like adding the text you proposed. COOKIE is the only option, nonce is not an option, as it is not sent back. => I don't buy this argument: I prefer Yonghui's one, i.e., cookie has already this connotation (a weak form of the "least astonishment" argument). Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 16 07:30:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27346 for ; Mon, 16 Aug 2004 07:30:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwfbd-0007sp-He; Mon, 16 Aug 2004 07:24:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwfV6-0007Dn-Rn for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 07:18:04 -0400 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 HAA26971 for ; Mon, 16 Aug 2004 07:18:04 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwfat-0007b5-CN for ipsec@ietf.org; Mon, 16 Aug 2004 07:24:03 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7GBEJg15971 for ; Mon, 16 Aug 2004 07:14:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7GBFAw4011621 for ; Mon, 16 Aug 2004 07:15:10 -0400 (EDT) Received: from p2.piuha.net(131.160.192.2) by nutshell.tislabs.com via csmap (V6.0) id srcAAAqTa4Pw; Mon, 16 Aug 04 07:15:06 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D85EE89868; Mon, 16 Aug 2004 14:17:52 +0300 (EEST) Message-ID: <412097C9.7080206@kolumbus.fi> Date: Mon, 16 Aug 2004 14:17:29 +0300 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: IPsec WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba Subject: [Ipsec] IKEv2 identifier issue with EAP 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 First some background: In traditional EAP usage, the client's identifier has been determined through the EAP Identity Request/Response exchange. The identifier is typically a Network Access Identifier (NAI). Basically an identifier similar to an e-mail address, used to identify the user and to find the right home network in case of a roaming user. IKEv2-14 says the following: Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used. it also defines one of the identity type as follows: ID_RFC822_ADDR 3 A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not contain any terminators. In the RADEXT and EAP WGs, we have recently discussed some problems that this causes. Here are the issues: 1. A revision of the NAI specification, RFC 2486bis, intends to extend the existing user@domain format in draft-arkko-roamops-rfc2486bis-02.txt, partially based on existing practise. This spec is currently in WGLC in the RADEXT WG. One of the extensions is to allow the client's identity to be hidden from the access server / IKEv2 gateway, if the used EAP method supports end-to-end encrypted tranmission of the identity. Syntactically, this happens through specifying an empty username, "@domain" but keeping the domain pawrt in order to make the AAA routing possible. The issue with IKEv2 is strictly speaking, this string would be illegal in RFC 822. Hence an IKEv2 implementation can not be relied upon to accept such "privacy" user names. 2. Another extension from this draft is internationalized NAIs. The domain parts are IDNs, i.e., converted to ASCII via a specific mapping, but the username part is UTF-8. Again, this is strictly speaking not conformant to RFC 822, so sending an internationalized username via IKEv2 might not be possible. For instance, someone might be assigned a username for WLAN access, but the usage of this username for IKEv2 purposes might not be possible if it contains international characters. Some of the possible solutions to avoid this problem include o Decide that support of privacy & international usernames is not necessary in IKEv2. o Remove the privacy and international username (not domain) parts from RFC 2486bis. o Change the international username part so that instead of UTF-8, it uses a IDN-like ASCII mapping which can represent non-ASCII characters but it looks like ASCII to the carrier. Either remove the privacy feature or just say it can not be used in all carrier protocols. o Define a new IKEv2 ID type to carry the new types NAIs. (If so, would this type be defined in the NAIbis, IKEv2 or some other draft?) o Rely on IKEv2 implementations to not check the contents of the identifier for RFC 822 compliance. o Go against the SHOULD NOT when the given NAI requires this. 3. Ongoing work (and some existing practise) provides some information through the EAP identity request. More specifically, the client can get a hint of what type of identifier it should offer. See draft-adrangi-eap-network-discovery-03.txt. This functionality does not appear to be present when running EAP over IKEv2. (I have not heard of any customer who wanted this functionality in this context, but I'd like to avoid special cases where possible.) Comments? --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 16 16:04:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01914 for ; Mon, 16 Aug 2004 16:04:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwn6H-0001yI-AM; Mon, 16 Aug 2004 15:24:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwn0b-0006o4-HK; Mon, 16 Aug 2004 15:19:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24642; Mon, 16 Aug 2004 15:19:03 -0400 (EDT) Message-Id: <200408161919.PAA24642@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 16 Aug 2004 15:19:03 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-ikev2-15.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: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-15.txt Pages : 109 Date : 2004-8-16 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-16153635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-16153635.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From ipsec-bounces@ietf.org Mon Aug 16 21:04:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26103 for ; Mon, 16 Aug 2004 21:04:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwsDS-0004hQ-QS; Mon, 16 Aug 2004 20:52:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwsD2-0004SL-QK for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 20:52:16 -0400 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 UAA25576 for ; Mon, 16 Aug 2004 20:52:15 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwsIw-0008Vf-JQ for ipsec@ietf.org; Mon, 16 Aug 2004 20:58:23 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7H0mTg02890 for ; Mon, 16 Aug 2004 20:48:29 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7H0nN1C024698 for ; Mon, 16 Aug 2004 20:49:23 -0400 (EDT) Received: from mail1.microsoft.com(131.107.3.125) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7kaapW; Mon, 16 Aug 04 20:49:21 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 16 Aug 2004 17:52:10 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 17:52:07 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IKEv2 identifier issue with EAP Date: Mon, 16 Aug 2004 17:52:12 -0700 Message-ID: Thread-Topic: [Ipsec] IKEv2 identifier issue with EAP Thread-Index: AcSDhIsjfE4A/v76TCu8+IkIn5ITngAbUgZw From: "Charlie Kaufman" To: "Jari Arkko" , "IPsec WG" X-OriginalArrivalTime: 17 Aug 2004 00:52:07.0798 (UTC) FILETIME=[6BDAD960:01C483F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba 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 I agree that this is likely to become a problem, that any of your 'possible solutions' could be used to fix it (except that I don't believe the first two 'define the problem away' were serious proposals), and that the community SHOULD agree on one standard approach to maximize interoperability. My favorite would be: o Go against the SHOULD NOT when the given NAI requires this. ...because this also addresses the identity type hint that you say might be coming. But others have argued heatedly that it is important to minimize the number of messages in an IKE exchange, and this would result in an eight message exchange while some of the other proposals work in six. I'm really glad it's not my job anymore to herd the cats towards one approach or the other. --Charlie p.s. If you are going to define a new ID type, it would need to be added to the IANA registry for IKEv2. The procedure for this is "expert review". It could probably be defined in some EAP RFC and ratified by some expert chosen by the security ADs, but I don't know. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Monday, August 16, 2004 4:17 AM To: IPsec WG Cc: Bernard Aboba Subject: [Ipsec] IKEv2 identifier issue with EAP First some background: In traditional EAP usage, the client's identifier has been determined through the EAP Identity Request/Response exchange. The identifier is typically a Network Access Identifier (NAI). Basically an identifier similar to an e-mail address, used to identify the user and to find the right home network in case of a roaming user. IKEv2-14 says the following: Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used. it also defines one of the identity type as follows: ID_RFC822_ADDR 3 A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not contain any terminators. In the RADEXT and EAP WGs, we have recently discussed some problems that this causes. Here are the issues: 1. A revision of the NAI specification, RFC 2486bis, intends to extend the existing user@domain format in draft-arkko-roamops-rfc2486bis-02.txt, partially based on existing practise. This spec is currently in WGLC in the RADEXT WG. One of the extensions is to allow the client's identity to be hidden from the access server / IKEv2 gateway, if the used EAP method supports end-to-end encrypted tranmission of the identity. Syntactically, this happens through specifying an empty username, "@domain" but keeping the domain pawrt in order to make the AAA routing possible. The issue with IKEv2 is strictly speaking, this string would be illegal in RFC 822. Hence an IKEv2 implementation can not be relied upon to accept such "privacy" user names. 2. Another extension from this draft is internationalized NAIs. The domain parts are IDNs, i.e., converted to ASCII via a specific mapping, but the username part is UTF-8. Again, this is strictly speaking not conformant to RFC 822, so sending an internationalized username via IKEv2 might not be possible. For instance, someone might be assigned a username for WLAN access, but the usage of this username for IKEv2 purposes might not be possible if it contains international characters. Some of the possible solutions to avoid this problem include o Decide that support of privacy & international usernames is not necessary in IKEv2. o Remove the privacy and international username (not domain) parts from RFC 2486bis. o Change the international username part so that instead of UTF-8, it uses a IDN-like ASCII mapping which can represent non-ASCII characters but it looks like ASCII to the carrier. Either remove the privacy feature or just say it can not be used in all carrier protocols. o Define a new IKEv2 ID type to carry the new types NAIs. (If so, would this type be defined in the NAIbis, IKEv2 or some other draft?) o Rely on IKEv2 implementations to not check the contents of the identifier for RFC 822 compliance. o Go against the SHOULD NOT when the given NAI requires this. 3. Ongoing work (and some existing practise) provides some information through the EAP identity request. More specifically, the client can get a hint of what type of identifier it should offer. See draft-adrangi-eap-network-discovery-03.txt. This functionality does not appear to be present when running EAP over IKEv2. (I have not heard of any customer who wanted this functionality in this context, but I'd like to avoid special cases where possible.) Comments? --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 16 21:09:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26386 for ; Mon, 16 Aug 2004 21:09:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwsQz-00077J-9W; Mon, 16 Aug 2004 21:06:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwsIU-0005XW-Vv for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 20:57:55 -0400 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 UAA25782 for ; Mon, 16 Aug 2004 20:57:53 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwsOO-00009K-8a for ipsec@ietf.org; Mon, 16 Aug 2004 21:04:01 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 16 Aug 2004 17:57:19 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 17:57:15 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IKE_SPI value Date: Mon, 16 Aug 2004 17:57:20 -0700 Message-ID: Thread-Topic: [Ipsec] IKE_SPI value Thread-Index: AcSCtuSXOHDO9590QTuTKMGPmWdnEABPbBmA From: "Charlie Kaufman" To: "khan wadood" , X-OriginalArrivalTime: 17 Aug 2004 00:57:16.0092 (UTC) FILETIME=[239CC7C0:01C483F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 The IKE_SPI could be random, sequential, or even a pointer into memory. An implementation is free to choose any 8 octets it wants, so long as it doesn't use the same octets for two different SAs at the same time. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of khan wadood Sent: Sunday, August 15, 2004 3:46 AM To: ipsec@ietf.org Subject: [Ipsec] IKE_SPI value hi, As the IKE_SPI is a unique 8 octets value. It is used to identify an IKE_SA. Is the IKE_SPI value choosen randomly or sequentially or it depends upon the implementation of particular vendor?? thanks in advance wadood =20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 16 21:44:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28179 for ; Mon, 16 Aug 2004 21:44:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwswo-0004n3-6Y; Mon, 16 Aug 2004 21:39:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwsto-0004Mc-Ii for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 21:36:28 -0400 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 VAA27877 for ; Mon, 16 Aug 2004 21:36:26 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwszi-0000qs-4K for ipsec@ietf.org; Mon, 16 Aug 2004 21:42:35 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 16 Aug 2004 18:35:55 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 18:35:53 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] comment on "empty message" in IKEv2 draft Date: Mon, 16 Aug 2004 18:35:54 -0700 Message-ID: Thread-Topic: [Ipsec] comment on "empty message" in IKEv2 draft Thread-Index: AcSDdosPG1mqn4BLQ+yIbpyhwY4XQgAf5KVw From: "Charlie Kaufman" To: "Francis Dupont" , "Tero Kivinen" X-OriginalArrivalTime: 17 Aug 2004 01:35:53.0403 (UTC) FILETIME=[88D660B0:01C483FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: Yonghui Cheng , 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 Issue: it might be useful in an otherwise empty "are you still there" Informational exchange to have the initiator place an unpredictable value in the request and have the responder echo it back. This prevents the (admittedly arcane) attack where the responder pre-generates a series of "yes I'm still here" messages and then forgets the session key. As the protocol exists today, you can't be sure that the responder still knows the session key - only that when he did he generated messages ahead. (I personally would prefer to ignore such threats, but it turns out there are some other more real uses for the protocol change in the context of MOBIKE). A discussion has taken place under this subject line as to whether it would be better to encode this unpredictable value as a nonce or a cookie. Tero writes: COOKIE is the only option, nonce is not an option, as it is not sent back. Francis responds: I don't buy this argument: I prefer Yonghui's one, i.e., cookie has already this connotation (a weak form of the "least astonishment" argument). Charlie chimes in: I agree with Francis that we can do whatever we want. It's a matter of taste which encoding is most natural in this context. I'd be happy with either one, but I would prefer a third. My logic follows: I consider it too late to get this into the IKEv2 spec. I hope I'm not wrong about that. If so, we should think of this as the first of many extensions to IKEv2. IKEv2 was designed for extensibility. If we can't make this one, we clearly blew it. The IKEv2 spec goes out of its way to say what an implementation is supposed to do if it gets a request it doesn't understand (sometimes it ignores it, sometimes it rejects it, etc). This is so that we can extend IKEv2 and predict how existing implementations will act when they see the extensions. But the spec doesn't say what to do if you get a payload that you *do* understand in a context where you don't expect it. Getting either a cookie or a nonce in an informational exchange is an example of such an event. I wish the spec had said to ignore such payloads, and I hope that without any guidance that is what implementations do. But it would be legal for them to do something else - like close the connection. So my preference would be to invent a new notify type for this purpose. Existing implementations *are* directed to ignore notification types they don't understand, so older implementations would not echo the nonce back, but neither would they complain. But this desire is only a matter of taste - in my case motivated by theoretical purity. Assuming we can get this recommendation out in less than a few years :-), all implementations of IKEv2 will handle either a cookie or a nonce correctly. --Charlie _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 16 21:58:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29693 for ; Mon, 16 Aug 2004 21:58:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwt4d-0006e2-Vs; Mon, 16 Aug 2004 21:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwt3u-0006MR-Hs for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 21:46:54 -0400 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 VAA28453 for ; Mon, 16 Aug 2004 21:46:52 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bwt9p-00013D-66 for ipsec@ietf.org; Mon, 16 Aug 2004 21:53:01 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 16 Aug 2004 18:46:22 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 18:46:04 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] comment on "empty message" in IKEv2 draft Date: Mon, 16 Aug 2004 18:46:04 -0700 Message-ID: Thread-Topic: [Ipsec] comment on "empty message" in IKEv2 draft Thread-Index: AcSAtENoNK3PnmHIT26eaMzASWrVwADRtOtQ From: "Charlie Kaufman" To: "Yonghui Cheng" X-OriginalArrivalTime: 17 Aug 2004 01:46:04.0591 (UTC) FILETIME=[F52243F0:01C483FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Russ Housley 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 While I believe the IKEv2 spec is unambiguous when read carefully, I agree that it would be clearer if it explicitly said that an "empty" message actually consists of an empty "encrypted payload". I don't think this warrants a new draft, but if something else requires a new draft (or if I'm allowed to make such minor changes during author's 48 hour call), I will fix it. --Charlie ________________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yonghui Cheng Sent: Thursday, August 12, 2004 2:35 PM To: ipsec@ietf.org Subject: [Ipsec] comment on "empty message" in IKEv2 draft All, The IKEv2 draft/RFC should emphasis that when send "empty" messages in IKEv2, the actual messages should include an empty "encrypted payload". "Empty" messages is used for DPD (dead peer detection) and acknowledge purposes. Without encrypted payload, the message is not authenticated, which should considered as security problem. Yonghui _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 17 03:48:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28149 for ; Tue, 17 Aug 2004 03:48:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwyeb-0003sC-3g; Tue, 17 Aug 2004 03:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwydP-0003cb-7v for ipsec@megatron.ietf.org; Tue, 17 Aug 2004 03:43:55 -0400 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 DAA27889 for ; Tue, 17 Aug 2004 03:43:53 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwyjL-0006Ol-W8 for ipsec@ietf.org; Tue, 17 Aug 2004 03:50:05 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7H7hRYu000693 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 17 Aug 2004 10:43:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7H7hQ8c000690; Tue, 17 Aug 2004 10:43:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16673.46878.582842.29207@fireball.kivinen.iki.fi> Date: Tue, 17 Aug 2004 10:43:26 +0300 From: Tero Kivinen To: "Charlie Kaufman" Subject: RE: [Ipsec] comment on "empty message" in IKEv2 draft In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Yonghui Cheng , ipsec@ietf.org, Francis Dupont 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 Charlie Kaufman writes: > I consider it too late to get this into the IKEv2 spec. I hope I'm not > wrong about that. If so, we should think of this as the first of many > extensions to IKEv2. IKEv2 was designed for extensibility. If we can't > make this one, we clearly blew it. Yes, I agree this is too late for IKEv2. We will probably define this in the MOBIKE WG. The reason this came up here in the ipsec list was to reply to the comment about the empty messages and dead peer detection. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 17 05:17:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02719 for ; Tue, 17 Aug 2004 05:17:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwzz8-0001SG-IE; Tue, 17 Aug 2004 05:10:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwzxB-0000ys-Fo for ipsec@megatron.ietf.org; Tue, 17 Aug 2004 05:08:25 -0400 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 FAA02327 for ; Tue, 17 Aug 2004 05:08:23 -0400 (EDT) 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 1Bx039-00082z-1X for ipsec@ietf.org; Tue, 17 Aug 2004 05:14:36 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7H98Kj12254; Tue, 17 Aug 2004 12:08:20 +0300 (EET DST) X-Scanned: Tue, 17 Aug 2004 12:08:05 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7H9850v025624; Tue, 17 Aug 2004 12:08:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00dxoxdZ; Tue, 17 Aug 2004 12:07:52 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7H97on26999; Tue, 17 Aug 2004 12:07:50 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 17 Aug 2004 12:07:40 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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] comment on "empty message" in IKEv2 draft Date: Tue, 17 Aug 2004 12:07:39 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3BD3@esebe023.ntc.nokia.com> Thread-Topic: [Ipsec] comment on "empty message" in IKEv2 draft Thread-Index: AcSDdosPG1mqn4BLQ+yIbpyhwY4XQgAf5KVwABDL9zA= To: , X-OriginalArrivalTime: 17 Aug 2004 09:07:40.0755 (UTC) FILETIME=[A6140A30:01C48439] X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Charlie Kaufman wrote: > > I consider it too late to get this into the IKEv2 spec. I hope I'm not > wrong about that. If so, we should think of this as the first of many > extensions to IKEv2. IKEv2 was designed for extensibility. If we can't > make this one, we clearly blew it. Yes, I agree it's too late, and this can be done as an extension (possibly at MOBIKE) later. Regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 17 05:27:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03212 for ; Tue, 17 Aug 2004 05:27:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx0Cg-0003rw-T5; Tue, 17 Aug 2004 05:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx0CW-0003kD-NJ for ipsec@megatron.ietf.org; Tue, 17 Aug 2004 05:24:16 -0400 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 FAA03065 for ; Tue, 17 Aug 2004 05:24:14 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx0IU-0008JC-DY for ipsec@ietf.org; Tue, 17 Aug 2004 05:30:27 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7H9KUg22235 for ; Tue, 17 Aug 2004 05:20:30 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7H9LLC5017002 for ; Tue, 17 Aug 2004 05:21:21 -0400 (EDT) Received: from unknown(213.255.194.27) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZHaGiH; Tue, 17 Aug 04 05:21:10 -0400 Date: Tue, 17 Aug 2004 10:24:00 +0100 To: "Ipsec" From: "Davenport" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ozxgflvamyfyygahgoqg" X-Spam-Score: 3.4 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Thanks :) 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 ----------ozxgflvamyfyygahgoqg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ozxgflvamyfyygahgoqg Content-Type: text/html; name="Details.cpl.htm" Content-Disposition: attachment; filename="Details.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Details.cpl
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------ozxgflvamyfyygahgoqg 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 ----------ozxgflvamyfyygahgoqg-- From ipsec-bounces@ietf.org Tue Aug 17 10:35:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19529 for ; Tue, 17 Aug 2004 10:35:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4xO-0006P1-Uu; Tue, 17 Aug 2004 10:28:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx4ts-0005io-G0 for ipsec@megatron.ietf.org; Tue, 17 Aug 2004 10:25:20 -0400 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 KAA18743 for ; Tue, 17 Aug 2004 10:25:18 -0400 (EDT) From: byfraser@cisco.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx4zs-0004zX-Ig for ipsec@ietf.org; Tue, 17 Aug 2004 10:31:34 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7HELWg18179 for ; Tue, 17 Aug 2004 10:21:32 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7HEMPDA004248 for ; Tue, 17 Aug 2004 10:22:25 -0400 (EDT) Received: from rndf-151-37.telkomadsl.co.za(165.165.151.37) by nutshell.tislabs.com via csmap (V6.0) id srcAAAm3aGli; Tue, 17 Aug 04 10:22:06 -0400 Date: Tue, 17 Aug 2004 07:27:48 -0800 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zkyedtjncpnlybsafaaz" X-Spam-Score: 3.2 (+++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Ipsec] Incoming message 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 ----------zkyedtjncpnlybsafaaz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Please, have a look at the attached file.

Attached file is protected with the password for security reasons. Password is

----------zkyedtjncpnlybsafaaz Content-Type: image/bmp; name="ejqwnxjwfz.bmp" Content-Disposition: attachment; filename="ejqwnxjwfz.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk2mBwAAAAAAADYAAAAoAAAANwAAABEAAAABABAAAAAAAHAHAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//wP/f+8B/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//fykDKQMpAykDKQMpAykDKQMpAykDKQMpAykD KQMpAykDKQMpAykDKQMpAykDKQMpAykDKQMpAykDKQMpAykDKQMpAykDKQP/f/9//3//f/9/ /3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f5Q/KQMpA7ZP/3//f/9/ lD8pAykDtk//f/9/tk8pAykDlD//f/9//3//f/9/KQMpA7lf/3//f7lfKQMpA5Q//3//f/9/ /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/lD8pA7lftk8pA7lf /3+UPykDuV+2TykDuV//fykDKQO5XykDlD//f/9//3//f5Q/KQO5X/9//3+UPykDtk8pA5Q/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//fykDKQP/f7lf KQOUP/9/KQMpA/9/uV8pA5Q//3//f/9//3+UPykDuV//f/9//3+2TykDtk//f/9/KQMpA/9/ KQMpA/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//38pAykD /3//fykDKQP/fykDKQP/f/9/KQMpA/9/uV+UPykDlD8pA5Q//3//f/9/tk8pA5Q//3//fykD KQP/fykDKQP/f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/ KQMpA7lf/38pAykD/38pAykDuV//fykDKQP/f5Q/KQO5X7ZPKQMpA/9//3//f7lfKQOUP/9/ /3+2TykDtk8pA5Q//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9/ /3//fykDKQOUP7lfKQOUP/9/KQMpA5Q/uV8pA5Q//38pAykD/3+5XykDKQP/f/9//3//fykD KQP/f/9//3+5XykDKQO2T/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3+UPykDlD8pA5Q/uV//f5Q/KQOUPykDlD+5X/9/KQMpA/9//38pAykD/3//f7lf /38pAykDuV//f/9/lD8pA7lfKQO2T/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ /3//f/9//3//f/9/uV8pA7ZP/3//f/9//3+5XykDtk//f/9//3//f5Q/KQO5X/9/KQMpA/9/ /38pAykDKQMpA7lf/3//fykDKQP/fykDKQP/f/9//3//f/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f/9/lD8pA7lfKQMpA/9//3+UPykDuV8pAykD/3+5XykDtk+5XykD lD//f/9/uV+2TykDKQO2T/9//3+UPykDuV8pAykD/3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9//3//f/9/lD8pAykDtk//f/9//3+UPykDKQO2T/9//3+2TykD KQOUP/9//3//f/9//3//f5Q/lD//f/9//3+UPykDKQO5X/9//3//f/9//3//f/9//3//f/9/ AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/AAA= ----------zkyedtjncpnlybsafaaz Content-Type: text/html; name="Details.zip.htm" Content-Disposition: attachment; filename="Details.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Details.zip
Virus name: W32/Bagle.gen@MM!pwdzip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------zkyedtjncpnlybsafaaz 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 ----------zkyedtjncpnlybsafaaz-- From ipsec-bounces@ietf.org Tue Aug 17 18:08:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18235 for ; Tue, 17 Aug 2004 18:08:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxBxQ-0004pg-67; Tue, 17 Aug 2004 17:57:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxBuY-0004H0-7D for ipsec@megatron.ietf.org; Tue, 17 Aug 2004 17:54:30 -0400 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 RAA17188 for ; Tue, 17 Aug 2004 17:54:27 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxC0d-0005Ht-Bo for ipsec@ietf.org; Tue, 17 Aug 2004 18:00:47 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7HLofg18313 for ; Tue, 17 Aug 2004 17:50:41 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7HLpXX8004845 for ; Tue, 17 Aug 2004 17:51:33 -0400 (EDT) Received: from email.quarrytech.com(4.17.144.4) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfaayCj; Tue, 17 Aug 04 17:51:31 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.45]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87XVD69; Tue, 17 Aug 2004 17:54:21 -0400 Message-Id: <6.1.2.0.2.20040817134843.02ec7b40@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 17 Aug 2004 17:34:37 -0400 To: Stephen Kent , ipsec@lists.tislabs.com, ipsec@ietf.org From: Mark Duffy Subject: Re: [Ipsec] new ICMP text for 2401bis In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 Steve, sorry about the delayed response. Please see some comments below. --Mark At 05:01 PM 8/9/2004, Stephen Kent wrote: [...] >6.1 ICMP message not protected by IPsec > >An ICMP message not protected by AH or ESP is unauthenticated and its >processing and/or forwarding may result in denial or degradation of >service. This suggests that, in general, it would be desirable to ignore >such messages. However, many ICMP messages will be received by hosts or >security gateways from unauthenticated sources, e.g., routers in the >public Internet. Ignoring these ICMP messages can degrade service, e.g., >because of a failure to process PMTU message and redirection messages. >Thus there is also a motivation for accepting and acting upon >unauthenticated ICMP messages. To accommodate both ends of this spectrum, >a compliant IPsec implementation MUST permit a local administrator to >configure an IPsec implementation to accept or reject unauthenticated ICMP >traffic. This control MUST be at the granularity of ICMP type and MAY be >at the granularity of ICMP type and code. No disagreement here with requiring that control, but wouldn't the SPD (already covered under other MUSTs) generally be sufficient to meet this requirement? > Additionally, an implementation SHOULD incorporate mechanisms and > parameters for dealing with such traffic. For example, there could be the > ability to establish a minimum PMTU for traffic (perhaps on a per > destination basis), to prevent receipt of an unauthenticated ICMP from > setting the PMTU to a trivial size." [See Section xxx for recommendations.] Is that SHOULD intended to apply to ICMP messages that are forwarded, or those that are addressed to the IPsec implementation itself, or both? >6.2 ICMP messages protected by IPsec > >(This section does NOT apply to ICMP traffic that is bypassed or consumed >on the ciphertext side of the IPsec boundary.) > >Both the payload of an ICMP error packet, and the header of the ICMP >packet require checking from an access control perspective. If one of >these packets is forwarded to a host behind a security gateway, the >receiving host IP implementation will make decisions based on the payload, >i.e., the header of the packet that purportedly triggered the error >response. Thus an IPsec implementation SHOULD to try to ensure that this >header information is >consistent with the IPsec peer that transmitted the ICMP packet. I don't think it is clear what it means to "ensure that this header information is consistent with the IPsec peer that transmitted the ICMP packet". How about "Thus an IPsec implementation receiving an IPsec protected ICMP message SHOULD try to ensure that the ICMP payload information is consistent with packets that would be sent on the SA pair on which the ICMP message was received." Why is this a SHOULD, but then below the specific actions required to achieve this are MUST? On the other hand, MUST isn't correct here either because in the case where there is an SA for the ICMP packet in its own right, this special check on the ICMP payload is not being called for. Maybe it should say it MUST do this under certain conditions as described below. > If this sort of check is not performed, then for example, anyone with > whom the receiving IPsec system (A) has an active SA could send an ICMP > destination dead message that refers to any host/net with which A is > currently communicating, and thus effect a highly efficient DoS attack re > communication with other peers of A. Normal IPsec receiver processing of > traffic is not sufficient to protect against such attacks. > >If no SA exists that matches the traffic selectors associated with an ICMP >error packet, I don't think that should say "if no SA exists ...". Rather, I think it should say "if no SPD entry exists that matches the traffic selectors associated with an ICMP error packet". I agree with the point below that it should not negotiate a new SA to forward an ICMP under the special processing rules (based on the ICMP payload). But I think it *should* negotiate a new SA if needed when operating under the usual rules (i.e. if there is an SPD entry that natively matches the ICMP packet). I assume that this would refer to SPD entries of any flavor (discard, bypass, protect) and so it is only if there is no SPD entry at all that matches the ICMP packet that it should then consider doing the special outbound processing described next... > then an IPsec implementation MUST map an outbound ICMP error packet to > the SA that would carry the return traffic associated with the packet > that triggered the ICMP error packet. (This allows an administrator to > explicitly account for ICMP error packets in SPD entries, causing them to > bypass the payload check noted below. This results in reduced security > for hosts, as noted above.) This requires an IPsec implementation to > detect outbound ICMP error packets that map to no extant SA, Pursuant to my point above, "that map to no extant SA" would need a corresponding change to refer to SPD policy rather than extant SA. > and treat them specially with regard to SA creation and lookup. The > implementation extracts the header for the packet that triggered the > error (from the ICMP message payload), reverses the source and > destination IP address fields, extracts the protocol field, and reverses > the port fields (if accessible). it them uses this extracted information > to locate an appropriate, active outbound SA. This implies that there > must be an active SA for that traffic. An IPsec implementation MUST NOT > create a new SA carry ICMP traffic error packets as a result of an > attempt to transmit such packets. > >If an IPsec implementation receives an IMCP error packet that does not >match the SA traffic selectors, the receiver also MUST process the >received message in a special fashion. Specifically, the receiver must >extract the header of the triggering packet from the ICMP payload, and >reverse fields as described above to determine if the packet is consistent >with the selectors for the SA s/if the packet/ if the triggering packet/ -- would add some clarity >via which it was received. Only then is it safe to forward the ICMP >message to the destination. > >The sender and receiver MUST support the following processing when ICMP >error packets are sent over SAs with selectors that DO NOT match these packets: > > a. If an IPsec implementation encounters an outbound ICMP error message > for which no applicable SA exists, as argued above, this should be a reference to SPD policy, not extant SA > it extracts the header info from > the payload, reverses the source and destination IP addresses, and, if > accessible, the source and destination port fields. It uses the address, > protocol, and port fields (if available) to perform an SPD lookup. If an > appropriate, extant SA is found, the packet is transmitted via this SA. > (No new SA will be created to carry an ICMP error packet.) If no > suitable > SA exists, the ICMP packet is dropped, an auditable event. > > b. If an IPsec implementation receives an ICMP error packet on an SA > and the > traffic selectors for that SA do not allow for the packet, a secondary > check is performed. The receiver extracts the header info from the ICMP > payload, reverses the source and destination IP addresses, and, if > accessible, the source and destination port fields. The resulting values > are compared to the selectors for the SA via which the ICMP packet was > received. If the selectors match, the packet is forwarded, otherwise it > it is discarded, and auditable event. [...] _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 17 18:08:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18280 for ; Tue, 17 Aug 2004 18:08:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxByI-0004xf-02; Tue, 17 Aug 2004 17:58:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxBuv-0004PR-M4 for ipsec@megatron.ietf.org; Tue, 17 Aug 2004 17:54:53 -0400 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 RAA17209 for ; Tue, 17 Aug 2004 17:54:50 -0400 (EDT) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxC10-0005Hk-Ta for ipsec@ietf.org; Tue, 17 Aug 2004 18:01:11 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.45]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87XVD69; Tue, 17 Aug 2004 17:54:21 -0400 Message-Id: <6.1.2.0.2.20040817134843.02ec7b40@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 17 Aug 2004 17:34:37 -0400 To: Stephen Kent , ipsec@lists.tislabs.com, ipsec@ietf.org From: Mark Duffy Subject: Re: [Ipsec] new ICMP text for 2401bis In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 Steve, sorry about the delayed response. Please see some comments below. --Mark At 05:01 PM 8/9/2004, Stephen Kent wrote: [...] >6.1 ICMP message not protected by IPsec > >An ICMP message not protected by AH or ESP is unauthenticated and its >processing and/or forwarding may result in denial or degradation of >service. This suggests that, in general, it would be desirable to ignore >such messages. However, many ICMP messages will be received by hosts or >security gateways from unauthenticated sources, e.g., routers in the >public Internet. Ignoring these ICMP messages can degrade service, e.g., >because of a failure to process PMTU message and redirection messages. >Thus there is also a motivation for accepting and acting upon >unauthenticated ICMP messages. To accommodate both ends of this spectrum, >a compliant IPsec implementation MUST permit a local administrator to >configure an IPsec implementation to accept or reject unauthenticated ICMP >traffic. This control MUST be at the granularity of ICMP type and MAY be >at the granularity of ICMP type and code. No disagreement here with requiring that control, but wouldn't the SPD (already covered under other MUSTs) generally be sufficient to meet this requirement? > Additionally, an implementation SHOULD incorporate mechanisms and > parameters for dealing with such traffic. For example, there could be the > ability to establish a minimum PMTU for traffic (perhaps on a per > destination basis), to prevent receipt of an unauthenticated ICMP from > setting the PMTU to a trivial size." [See Section xxx for recommendations.] Is that SHOULD intended to apply to ICMP messages that are forwarded, or those that are addressed to the IPsec implementation itself, or both? >6.2 ICMP messages protected by IPsec > >(This section does NOT apply to ICMP traffic that is bypassed or consumed >on the ciphertext side of the IPsec boundary.) > >Both the payload of an ICMP error packet, and the header of the ICMP >packet require checking from an access control perspective. If one of >these packets is forwarded to a host behind a security gateway, the >receiving host IP implementation will make decisions based on the payload, >i.e., the header of the packet that purportedly triggered the error >response. Thus an IPsec implementation SHOULD to try to ensure that this >header information is >consistent with the IPsec peer that transmitted the ICMP packet. I don't think it is clear what it means to "ensure that this header information is consistent with the IPsec peer that transmitted the ICMP packet". How about "Thus an IPsec implementation receiving an IPsec protected ICMP message SHOULD try to ensure that the ICMP payload information is consistent with packets that would be sent on the SA pair on which the ICMP message was received." Why is this a SHOULD, but then below the specific actions required to achieve this are MUST? On the other hand, MUST isn't correct here either because in the case where there is an SA for the ICMP packet in its own right, this special check on the ICMP payload is not being called for. Maybe it should say it MUST do this under certain conditions as described below. > If this sort of check is not performed, then for example, anyone with > whom the receiving IPsec system (A) has an active SA could send an ICMP > destination dead message that refers to any host/net with which A is > currently communicating, and thus effect a highly efficient DoS attack re > communication with other peers of A. Normal IPsec receiver processing of > traffic is not sufficient to protect against such attacks. > >If no SA exists that matches the traffic selectors associated with an ICMP >error packet, I don't think that should say "if no SA exists ...". Rather, I think it should say "if no SPD entry exists that matches the traffic selectors associated with an ICMP error packet". I agree with the point below that it should not negotiate a new SA to forward an ICMP under the special processing rules (based on the ICMP payload). But I think it *should* negotiate a new SA if needed when operating under the usual rules (i.e. if there is an SPD entry that natively matches the ICMP packet). I assume that this would refer to SPD entries of any flavor (discard, bypass, protect) and so it is only if there is no SPD entry at all that matches the ICMP packet that it should then consider doing the special outbound processing described next... > then an IPsec implementation MUST map an outbound ICMP error packet to > the SA that would carry the return traffic associated with the packet > that triggered the ICMP error packet. (This allows an administrator to > explicitly account for ICMP error packets in SPD entries, causing them to > bypass the payload check noted below. This results in reduced security > for hosts, as noted above.) This requires an IPsec implementation to > detect outbound ICMP error packets that map to no extant SA, Pursuant to my point above, "that map to no extant SA" would need a corresponding change to refer to SPD policy rather than extant SA. > and treat them specially with regard to SA creation and lookup. The > implementation extracts the header for the packet that triggered the > error (from the ICMP message payload), reverses the source and > destination IP address fields, extracts the protocol field, and reverses > the port fields (if accessible). it them uses this extracted information > to locate an appropriate, active outbound SA. This implies that there > must be an active SA for that traffic. An IPsec implementation MUST NOT > create a new SA carry ICMP traffic error packets as a result of an > attempt to transmit such packets. > >If an IPsec implementation receives an IMCP error packet that does not >match the SA traffic selectors, the receiver also MUST process the >received message in a special fashion. Specifically, the receiver must >extract the header of the triggering packet from the ICMP payload, and >reverse fields as described above to determine if the packet is consistent >with the selectors for the SA s/if the packet/ if the triggering packet/ -- would add some clarity >via which it was received. Only then is it safe to forward the ICMP >message to the destination. > >The sender and receiver MUST support the following processing when ICMP >error packets are sent over SAs with selectors that DO NOT match these packets: > > a. If an IPsec implementation encounters an outbound ICMP error message > for which no applicable SA exists, as argued above, this should be a reference to SPD policy, not extant SA > it extracts the header info from > the payload, reverses the source and destination IP addresses, and, if > accessible, the source and destination port fields. It uses the address, > protocol, and port fields (if available) to perform an SPD lookup. If an > appropriate, extant SA is found, the packet is transmitted via this SA. > (No new SA will be created to carry an ICMP error packet.) If no > suitable > SA exists, the ICMP packet is dropped, an auditable event. > > b. If an IPsec implementation receives an ICMP error packet on an SA > and the > traffic selectors for that SA do not allow for the packet, a secondary > check is performed. The receiver extracts the header info from the ICMP > payload, reverses the source and destination IP addresses, and, if > accessible, the source and destination port fields. The resulting values > are compared to the selectors for the SA via which the ICMP packet was > received. If the selectors match, the packet is forwarded, otherwise it > it is discarded, and auditable event. [...] _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 18 18:00:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23805 for ; Wed, 18 Aug 2004 18:00:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxYJO-0002OY-Dx; Wed, 18 Aug 2004 17:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxY4U-0006Ru-21 for ipsec@megatron.ietf.org; Wed, 18 Aug 2004 17:34:14 -0400 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 RAA21833 for ; Wed, 18 Aug 2004 17:34:11 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxYAl-000374-7E for ipsec@ietf.org; Wed, 18 Aug 2004 17:40:44 -0400 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 i7ILXejf025461; Wed, 18 Aug 2004 17:33:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20040817134843.02ec7b40@email> References: <6.1.2.0.2.20040817134843.02ec7b40@email> Date: Wed, 18 Aug 2004 17:31:58 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] new ICMP text for 2401bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: ipsec@ietf.org, ipsec@lists.tislabs.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 At 5:34 PM -0400 8/17/04, Mark Duffy wrote: >Steve, sorry about the delayed response. Please see some comments below. >--Mark > >At 05:01 PM 8/9/2004, Stephen Kent wrote: >[...] >>6.1 ICMP message not protected by IPsec >> >>An ICMP message not protected by AH or ESP is unauthenticated and >>its processing and/or forwarding may result in denial or >>degradation of service. This suggests that, in general, it would >>be desirable to ignore such messages. However, many ICMP messages >>will be received by hosts or security gateways from unauthenticated >>sources, e.g., routers in the public Internet. Ignoring these ICMP >>messages can degrade service, e.g., because of a failure to process >>PMTU message and redirection messages. Thus there is also a >>motivation for accepting and acting upon unauthenticated ICMP >>messages. To accommodate both ends of this spectrum, a compliant >>IPsec implementation MUST permit a local administrator to configure >>an IPsec implementation to accept or reject unauthenticated ICMP >>traffic. This control MUST be at the granularity of ICMP type and >>MAY be at the granularity of ICMP type and code. > >No disagreement here with requiring that control, but wouldn't the >SPD (already covered under other MUSTs) generally be sufficient to >meet this requirement? In Figure 3 in 2401bis we show processing of unprotected side, inbound ICMP traffic in its own box, not crossing the IPsec boundary. Also, if we want to do something like place a restriction on how small a PMTU size we are willing to believe based on an unauthenticated ICMP message received on this side(the example below), that is not the kind of thing we express via the SPD. >> Additionally, an implementation SHOULD incorporate mechanisms and >>parameters for dealing with such traffic. For example, there could >>be the ability to establish a minimum PMTU for traffic (perhaps on >>a per destination basis), to prevent receipt of an unauthenticated >>ICMP from setting the PMTU to a trivial size." [See Section xxx >>for recommendations.] > >Is that SHOULD intended to apply to ICMP messages that are >forwarded, or those that are addressed to the IPsec implementation >itself, or both? I intended for this to apply to unauthenticated messages, not ones arriving on an SA, so they would be addressed to the IPsec implementation itself. However, I was not thinking about messages that are bypassed, when I wrote that. Such messages must be accounted for in the SPD, or they would not be allowed across the IPsec boundary, but I am not suggesting that such messages, if bypassed, need to be subjected to additional "reasonableness" checks. >>6.2 ICMP messages protected by IPsec >> >>(This section does NOT apply to ICMP traffic that is bypassed or >>consumed on the ciphertext side of the IPsec boundary.) >> >>Both the payload of an ICMP error packet, and the header of the >>ICMP packet require checking from an access control perspective. If >>one of these packets is forwarded to a host behind a security >>gateway, the receiving host IP implementation will make decisions >>based on the payload, i.e., the header of the packet that >>purportedly triggered the error response. Thus an IPsec >>implementation SHOULD to try to ensure that this header information >>is >>consistent with the IPsec peer that transmitted the ICMP packet. > >I don't think it is clear what it means to "ensure that this header >information is consistent with the IPsec peer that transmitted the >ICMP packet". How about >"Thus an IPsec implementation receiving an IPsec protected ICMP >message SHOULD try to ensure that the ICMP payload information is >consistent with packets that would be sent on the SA pair on which >the ICMP message was received." Howe about: "An IPsec implementation MUST be capable of being configured to verify that the ICMP payload information is consistent with packets that would be sent on the SA pair on which the ICMP message was received." >Why is this a SHOULD, but then below the specific actions required >to achieve this are MUST? On the other hand, MUST isn't correct >here either because in the case where there is an SA for the ICMP >packet in its own right, this special check on the ICMP payload is >not being called for. Maybe it should say it MUST do this under >certain conditions as described below. My revised text makes the ability to do this a MUST, but also recognizes that one can choose to configure the SPD so that this will not happen. >> If this sort of check is not performed, then for example, anyone >>with whom the receiving IPsec system (A) has an active SA could >>send an ICMP destination dead message that refers to any host/net >>with which A is currently communicating, and thus effect a highly >>efficient DoS attack re communication with other peers of A. >>Normal IPsec receiver processing of traffic is not sufficient to >>protect against such attacks. >> >>If no SA exists that matches the traffic selectors associated with >>an ICMP error packet, > >I don't think that should say "if no SA exists ...". Rather, I >think it should say "if no SPD entry exists that matches the traffic >selectors associated with an ICMP error packet". I agree with the >point below that it should not negotiate a new SA to forward an ICMP >under the special processing rules (based on the ICMP payload). But >I think it *should* negotiate a new SA if needed when operating >under the usual rules (i.e. if there is an SPD entry that natively >matches the ICMP packet). My rationale was that since we are talking about ICMP error messages, they should never cause an SA to be created, because they should be sent only in response to receipt of a packet that arrived over an SA, causing the error in question. Hence I did mean that we should never create an SA to carry these messages. >I assume that this would refer to SPD entries of any flavor >(discard, bypass, protect) and so it is only if there is no SPD >entry at all that matches the ICMP packet that it should then >consider doing the special outbound processing described next... yes, it applies to all SPD entry types. >>then an IPsec implementation MUST map an outbound ICMP error packet >>to the SA that would carry the return traffic associated with the >>packet that triggered the ICMP error packet. (This allows an >>administrator to explicitly account for ICMP error packets in SPD >>entries, causing them to bypass the payload check noted below. This >>results in reduced security for hosts, as noted above.) This >>requires an IPsec implementation to detect outbound ICMP error >>packets that map to no extant SA, > >Pursuant to my point above, "that map to no extant SA" would need a >corresponding change to refer to SPD policy rather than extant SA. see my response above re this issue. >> and treat them specially with regard to SA creation and lookup. >>The implementation extracts the header for the packet that >>triggered the error (from the ICMP message payload), reverses the >>source and destination IP address fields, extracts the protocol >>field, and reverses the port fields (if accessible). it them uses >>this extracted information to locate an appropriate, active >>outbound SA. This implies that there must be an active SA for that >>traffic. An IPsec implementation MUST NOT create a new SA carry >>ICMP traffic error packets as a result of an attempt to transmit >>such packets. >> >>If an IPsec implementation receives an IMCP error packet that does >>not match the SA traffic selectors, the receiver also MUST process >>the received message in a special fashion. Specifically, the >>receiver must extract the header of the triggering packet from the >>ICMP payload, and reverse fields as described above to determine if >>the packet is consistent with the selectors for the SA > >s/if the packet/ if the triggering packet/ -- would add some clarity OK< we'll make the suggested change here. >>via which it was received. Only then is it safe to forward the ICMP >>message to the destination. >> >>The sender and receiver MUST support the following processing when >>ICMP error packets are sent over SAs with selectors that DO NOT >>match these packets: >> >> a. If an IPsec implementation encounters an outbound ICMP error message >> for which no applicable SA exists, > >as argued above, this should be a reference to SPD policy, not extant SA see response earlier. [SNIP] Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 18 18:48:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23808 for ; Wed, 18 Aug 2004 18:00:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxYJT-0002Q4-I1; Wed, 18 Aug 2004 17:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxY4d-0006cc-8E for ipsec@megatron.ietf.org; Wed, 18 Aug 2004 17:34:23 -0400 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 RAA21857 for ; Wed, 18 Aug 2004 17:34:20 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxYAv-00038v-DE for ipsec@ietf.org; Wed, 18 Aug 2004 17:40:53 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7ILUZg00387 for ; Wed, 18 Aug 2004 17:30:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7ILVUtT028548 for ; Wed, 18 Aug 2004 17:31:30 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAAeaa4S3; Wed, 18 Aug 04 17:31:24 -0400 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 i7ILXejf025461; Wed, 18 Aug 2004 17:33:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20040817134843.02ec7b40@email> References: <6.1.2.0.2.20040817134843.02ec7b40@email> Date: Wed, 18 Aug 2004 17:31:58 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] new ICMP text for 2401bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: ipsec@ietf.org, ipsec@lists.tislabs.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 At 5:34 PM -0400 8/17/04, Mark Duffy wrote: >Steve, sorry about the delayed response. Please see some comments below. >--Mark > >At 05:01 PM 8/9/2004, Stephen Kent wrote: >[...] >>6.1 ICMP message not protected by IPsec >> >>An ICMP message not protected by AH or ESP is unauthenticated and >>its processing and/or forwarding may result in denial or >>degradation of service. This suggests that, in general, it would >>be desirable to ignore such messages. However, many ICMP messages >>will be received by hosts or security gateways from unauthenticated >>sources, e.g., routers in the public Internet. Ignoring these ICMP >>messages can degrade service, e.g., because of a failure to process >>PMTU message and redirection messages. Thus there is also a >>motivation for accepting and acting upon unauthenticated ICMP >>messages. To accommodate both ends of this spectrum, a compliant >>IPsec implementation MUST permit a local administrator to configure >>an IPsec implementation to accept or reject unauthenticated ICMP >>traffic. This control MUST be at the granularity of ICMP type and >>MAY be at the granularity of ICMP type and code. > >No disagreement here with requiring that control, but wouldn't the >SPD (already covered under other MUSTs) generally be sufficient to >meet this requirement? In Figure 3 in 2401bis we show processing of unprotected side, inbound ICMP traffic in its own box, not crossing the IPsec boundary. Also, if we want to do something like place a restriction on how small a PMTU size we are willing to believe based on an unauthenticated ICMP message received on this side(the example below), that is not the kind of thing we express via the SPD. >> Additionally, an implementation SHOULD incorporate mechanisms and >>parameters for dealing with such traffic. For example, there could >>be the ability to establish a minimum PMTU for traffic (perhaps on >>a per destination basis), to prevent receipt of an unauthenticated >>ICMP from setting the PMTU to a trivial size." [See Section xxx >>for recommendations.] > >Is that SHOULD intended to apply to ICMP messages that are >forwarded, or those that are addressed to the IPsec implementation >itself, or both? I intended for this to apply to unauthenticated messages, not ones arriving on an SA, so they would be addressed to the IPsec implementation itself. However, I was not thinking about messages that are bypassed, when I wrote that. Such messages must be accounted for in the SPD, or they would not be allowed across the IPsec boundary, but I am not suggesting that such messages, if bypassed, need to be subjected to additional "reasonableness" checks. >>6.2 ICMP messages protected by IPsec >> >>(This section does NOT apply to ICMP traffic that is bypassed or >>consumed on the ciphertext side of the IPsec boundary.) >> >>Both the payload of an ICMP error packet, and the header of the >>ICMP packet require checking from an access control perspective. If >>one of these packets is forwarded to a host behind a security >>gateway, the receiving host IP implementation will make decisions >>based on the payload, i.e., the header of the packet that >>purportedly triggered the error response. Thus an IPsec >>implementation SHOULD to try to ensure that this header information >>is >>consistent with the IPsec peer that transmitted the ICMP packet. > >I don't think it is clear what it means to "ensure that this header >information is consistent with the IPsec peer that transmitted the >ICMP packet". How about >"Thus an IPsec implementation receiving an IPsec protected ICMP >message SHOULD try to ensure that the ICMP payload information is >consistent with packets that would be sent on the SA pair on which >the ICMP message was received." Howe about: "An IPsec implementation MUST be capable of being configured to verify that the ICMP payload information is consistent with packets that would be sent on the SA pair on which the ICMP message was received." >Why is this a SHOULD, but then below the specific actions required >to achieve this are MUST? On the other hand, MUST isn't correct >here either because in the case where there is an SA for the ICMP >packet in its own right, this special check on the ICMP payload is >not being called for. Maybe it should say it MUST do this under >certain conditions as described below. My revised text makes the ability to do this a MUST, but also recognizes that one can choose to configure the SPD so that this will not happen. >> If this sort of check is not performed, then for example, anyone >>with whom the receiving IPsec system (A) has an active SA could >>send an ICMP destination dead message that refers to any host/net >>with which A is currently communicating, and thus effect a highly >>efficient DoS attack re communication with other peers of A. >>Normal IPsec receiver processing of traffic is not sufficient to >>protect against such attacks. >> >>If no SA exists that matches the traffic selectors associated with >>an ICMP error packet, > >I don't think that should say "if no SA exists ...". Rather, I >think it should say "if no SPD entry exists that matches the traffic >selectors associated with an ICMP error packet". I agree with the >point below that it should not negotiate a new SA to forward an ICMP >under the special processing rules (based on the ICMP payload). But >I think it *should* negotiate a new SA if needed when operating >under the usual rules (i.e. if there is an SPD entry that natively >matches the ICMP packet). My rationale was that since we are talking about ICMP error messages, they should never cause an SA to be created, because they should be sent only in response to receipt of a packet that arrived over an SA, causing the error in question. Hence I did mean that we should never create an SA to carry these messages. >I assume that this would refer to SPD entries of any flavor >(discard, bypass, protect) and so it is only if there is no SPD >entry at all that matches the ICMP packet that it should then >consider doing the special outbound processing described next... yes, it applies to all SPD entry types. >>then an IPsec implementation MUST map an outbound ICMP error packet >>to the SA that would carry the return traffic associated with the >>packet that triggered the ICMP error packet. (This allows an >>administrator to explicitly account for ICMP error packets in SPD >>entries, causing them to bypass the payload check noted below. This >>results in reduced security for hosts, as noted above.) This >>requires an IPsec implementation to detect outbound ICMP error >>packets that map to no extant SA, > >Pursuant to my point above, "that map to no extant SA" would need a >corresponding change to refer to SPD policy rather than extant SA. see my response above re this issue. >> and treat them specially with regard to SA creation and lookup. >>The implementation extracts the header for the packet that >>triggered the error (from the ICMP message payload), reverses the >>source and destination IP address fields, extracts the protocol >>field, and reverses the port fields (if accessible). it them uses >>this extracted information to locate an appropriate, active >>outbound SA. This implies that there must be an active SA for that >>traffic. An IPsec implementation MUST NOT create a new SA carry >>ICMP traffic error packets as a result of an attempt to transmit >>such packets. >> >>If an IPsec implementation receives an IMCP error packet that does >>not match the SA traffic selectors, the receiver also MUST process >>the received message in a special fashion. Specifically, the >>receiver must extract the header of the triggering packet from the >>ICMP payload, and reverse fields as described above to determine if >>the packet is consistent with the selectors for the SA > >s/if the packet/ if the triggering packet/ -- would add some clarity OK< we'll make the suggested change here. >>via which it was received. Only then is it safe to forward the ICMP >>message to the destination. >> >>The sender and receiver MUST support the following processing when >>ICMP error packets are sent over SAs with selectors that DO NOT >>match these packets: >> >> a. If an IPsec implementation encounters an outbound ICMP error message >> for which no applicable SA exists, > >as argued above, this should be a reference to SPD policy, not extant SA see response earlier. [SNIP] Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 19 19:16:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18181 for ; Thu, 19 Aug 2004 19:16:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxw3e-0001fn-TY; Thu, 19 Aug 2004 19:10:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxw0b-00014r-Me for ipsec@megatron.ietf.org; Thu, 19 Aug 2004 19:07:49 -0400 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 TAA17823 for ; Thu, 19 Aug 2004 19:07:47 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxw77-0001Bu-4B for ipsec@ietf.org; Thu, 19 Aug 2004 19:14:34 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7JN3wg07057 for ; Thu, 19 Aug 2004 19:03:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7JN4t0u026468 for ; Thu, 19 Aug 2004 19:04:55 -0400 (EDT) Received: from email.quarrytech.com(4.17.144.4) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4taWRZ; Thu, 19 Aug 04 19:04:53 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.45]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87XVNFK; Thu, 19 Aug 2004 19:07:43 -0400 Message-Id: <6.1.2.0.2.20040819163019.02d554b8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 19 Aug 2004 19:06:38 -0400 To: Stephen Kent From: Mark Duffy Subject: Re: [Ipsec] new ICMP text for 2401bis In-Reply-To: References: <6.1.2.0.2.20040817134843.02ec7b40@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: ipsec@ietf.org, ipsec@lists.tislabs.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 Thanks Steve. Some more comments below. ...Mark At 05:31 PM 8/18/2004, Stephen Kent wrote: >At 5:34 PM -0400 8/17/04, Mark Duffy wrote: >>Steve, sorry about the delayed response. Please see some comments below. >>--Mark >> >>At 05:01 PM 8/9/2004, Stephen Kent wrote: >>[...] >>>6.1 ICMP message not protected by IPsec >>> >>>An ICMP message not protected by AH or ESP is unauthenticated and its >>>processing and/or forwarding may result in denial or degradation of >>>service. This suggests that, in general, it would be desirable to >>>ignore such messages. However, many ICMP messages will be received by >>>hosts or security gateways from unauthenticated sources, e.g., routers >>>in the public Internet. Ignoring these ICMP messages can degrade >>>service, e.g., because of a failure to process PMTU message and >>>redirection messages. Thus there is also a motivation for accepting and >>>acting upon unauthenticated ICMP messages. To accommodate both ends of >>>this spectrum, a compliant IPsec implementation MUST permit a local >>>administrator to configure an IPsec implementation to accept or reject >>>unauthenticated ICMP traffic. This control MUST be at the granularity >>>of ICMP type and MAY be at the granularity of ICMP type and code. >> >>No disagreement here with requiring that control, but wouldn't the SPD >>(already covered under other MUSTs) generally be sufficient to meet this >>requirement? > >In Figure 3 in 2401bis we show processing of unprotected side, inbound >ICMP traffic in its own box, not crossing the IPsec boundary. Also, if we >want to do something like place a restriction on how small a PMTU size we >are willing to believe based on an unauthenticated ICMP message received >on this side(the example below), that is not the kind of thing we express >via the SPD. Ahh, I looked only at figure 1 before speaking; I should have dug deeper :-) But, let me then pose a more basic question: *Why* is the reception of inbound ICMP traffic done outside the IPsec boundary? IKE is inside the boundary. Why should ICMP be different? And what about other protocols destined to the IPsec device itself, such as tcp and ospf? The figure doesn't show where these are, but I would hope/expect that they are also inside the IPsec boundary. As far as applying other restrictions such as min PMTU size, agreed that such checks cannot be expressed via the SPD. But that doesn't mean they can't be checked "behind" (after, inside) the SPD. >>> Additionally, an implementation SHOULD incorporate mechanisms and >>> parameters for dealing with such traffic. For example, there could be >>> the ability to establish a minimum PMTU for traffic (perhaps on a per >>> destination basis), to prevent receipt of an unauthenticated ICMP from >>> setting the PMTU to a trivial size." [See Section xxx for recommendations.] >> >>Is that SHOULD intended to apply to ICMP messages that are forwarded, or >>those that are addressed to the IPsec implementation itself, or both? > >I intended for this to apply to unauthenticated messages, not ones >arriving on an SA, so they would be addressed to the IPsec implementation >itself. However, I was not thinking about messages that are bypassed, when >I wrote that. Such messages must be accounted for in the SPD, or they >would not be allowed across the IPsec boundary, but I am not suggesting >that such messages, if bypassed, need to be subjected to additional >"reasonableness" checks. ok. perhaps the text can be clarified. I guess it should clarify that: -- the statement "a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic" refers only to ICMP addressed to the implementation itself (the SPD is already sufficient to handle this for transit bypassed ICMP). -- the extra "SHOULD" checks (like min PMTU) apply only to ICMP addressed to the implementation itself. Are those in line with your intent? >>>6.2 ICMP messages protected by IPsec >>> >>>(This section does NOT apply to ICMP traffic that is bypassed or >>>consumed on the ciphertext side of the IPsec boundary.) >>> >>>Both the payload of an ICMP error packet, and the header of the ICMP >>>packet require checking from an access control perspective. If one of >>>these packets is forwarded to a host behind a security gateway, the >>>receiving host IP implementation will make decisions based on the >>>payload, i.e., the header of the packet that purportedly triggered the >>>error response. Thus an IPsec implementation SHOULD to try to ensure >>>that this header information is >>>consistent with the IPsec peer that transmitted the ICMP packet. >> >>I don't think it is clear what it means to "ensure that this header >>information is consistent with the IPsec peer that transmitted the ICMP >>packet". How about >>"Thus an IPsec implementation receiving an IPsec protected ICMP message >>SHOULD try to ensure that the ICMP payload information is consistent with >>packets that would be sent on the SA pair on which the ICMP message was >>received." > >Howe about: > >"An IPsec implementation MUST be capable of being configured to verify >that the ICMP payload information is consistent with packets that would be >sent on the SA pair on which the ICMP message was received." good text, but see below. >>Why is this a SHOULD, but then below the specific actions required to >>achieve this are MUST? On the other hand, MUST isn't correct here either >>because in the case where there is an SA for the ICMP packet in its own >>right, this special check on the ICMP payload is not being called >>for. Maybe it should say it MUST do this under certain conditions as >>described below. > >My revised text makes the ability to do this a MUST, but also recognizes >that one can choose to configure the SPD so that this will not happen. But, I don't think it should really let them choose in that manner. In fact the rest of the text doesn't say 'let them choose', it says essentially 'always do the icmp payload check when forwarding icmp error messages on an SA where they don't match the selectors, but never check the icmp payload when forwarding the error messages on an SA where the ICMP packets do match the selectors'. I think the source of the confusion here, for me anyway, is that the 2nd paragraph in 6.2 ("Both the payload...") describes the possible attack and then makes some requirements for checking the icmp payload (such as your reworded text above) but then the following paragraphs (correctly I believe) call for doing this check only in the case where the ICMP packets are forwarded on an SA where they don't match the selectors. I'd recommend that 6.2 include something like: For ICMP messages sent on an SA with selectors that match the ICMP packet itself, an IPsec implementation MUST NOT verify the ICMP Payload information. For ICMP messages sent on an SA with selectors that do not match the ICMP packet, an IPsec implementation MUST be configurable to verify that the ICMP payload information is consistent with packets that would be sent on the SA pair on which the ICMP message was received. Or better yet, omit all that and just move all discussion about checking the ICMP payload to inside the description of the case where ICMP messages are sent on an SA with selectors that do not match the ICMP packet. >>> If this sort of check is not performed, then for example, anyone with >>> whom the receiving IPsec system (A) has an active SA could send an ICMP >>> destination dead message that refers to any host/net with which A is >>> currently communicating, and thus effect a highly efficient DoS attack >>> re communication with other peers of A. Normal IPsec receiver >>> processing of traffic is not sufficient to protect against such attacks. >>> >>>If no SA exists that matches the traffic selectors associated with an >>>ICMP error packet, >> >>I don't think that should say "if no SA exists ...". Rather, I think it >>should say "if no SPD entry exists that matches the traffic selectors >>associated with an ICMP error packet". I agree with the point below that >>it should not negotiate a new SA to forward an ICMP under the special >>processing rules (based on the ICMP payload). But I think it *should* >>negotiate a new SA if needed when operating under the usual rules (i.e. >>if there is an SPD entry that natively matches the ICMP packet). > >My rationale was that since we are talking about ICMP error messages, they >should never cause an SA to be created, because they should be sent only >in response to receipt of a packet that arrived over an SA, causing the >error in question. Hence I did mean that we should never create an SA to >carry these messages. I can understand the motivation, but suppose you have an SPD like this: 1. SA=a, DA=b, protocol=tcp, SP=*, DP=* --> protect 2. SA=a, DA=b, protocol=icmp, type=*, code=* --> protect or even like this: 1. SA=a, DA=b, protocol=tcp, SP=*, DP=* --> protect 2. SA=a, DA=b, protocol=* --> protect Then a tcp session starts up and an SA is opened under rule #1. Then an ICMP is generated for a tcp packet in that session. As written, the text would not permit an SA to be opened under rule #2 to forward that ICMP. This seems wrong to me, unless we have a rule in IPsec that says "never open a new SA for an IPsec error message". I do agree that if the SPD contains only rule #1, a new SA under rule #1 should not be opened merely to forward an ICMP error message. [snip] _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 19 19:18:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18320 for ; Thu, 19 Aug 2004 19:18:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxw3f-0001fy-Ry; Thu, 19 Aug 2004 19:10:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxw12-00018I-55 for ipsec@megatron.ietf.org; Thu, 19 Aug 2004 19:08:16 -0400 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 TAA17849 for ; Thu, 19 Aug 2004 19:08:13 -0400 (EDT) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxw7X-0001Bs-Rv for ipsec@ietf.org; Thu, 19 Aug 2004 19:15:00 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.45]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87XVNFK; Thu, 19 Aug 2004 19:07:43 -0400 Message-Id: <6.1.2.0.2.20040819163019.02d554b8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 19 Aug 2004 19:06:38 -0400 To: Stephen Kent From: Mark Duffy Subject: Re: [Ipsec] new ICMP text for 2401bis In-Reply-To: References: <6.1.2.0.2.20040817134843.02ec7b40@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: ipsec@ietf.org, ipsec@lists.tislabs.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 Thanks Steve. Some more comments below. ...Mark At 05:31 PM 8/18/2004, Stephen Kent wrote: >At 5:34 PM -0400 8/17/04, Mark Duffy wrote: >>Steve, sorry about the delayed response. Please see some comments below. >>--Mark >> >>At 05:01 PM 8/9/2004, Stephen Kent wrote: >>[...] >>>6.1 ICMP message not protected by IPsec >>> >>>An ICMP message not protected by AH or ESP is unauthenticated and its >>>processing and/or forwarding may result in denial or degradation of >>>service. This suggests that, in general, it would be desirable to >>>ignore such messages. However, many ICMP messages will be received by >>>hosts or security gateways from unauthenticated sources, e.g., routers >>>in the public Internet. Ignoring these ICMP messages can degrade >>>service, e.g., because of a failure to process PMTU message and >>>redirection messages. Thus there is also a motivation for accepting and >>>acting upon unauthenticated ICMP messages. To accommodate both ends of >>>this spectrum, a compliant IPsec implementation MUST permit a local >>>administrator to configure an IPsec implementation to accept or reject >>>unauthenticated ICMP traffic. This control MUST be at the granularity >>>of ICMP type and MAY be at the granularity of ICMP type and code. >> >>No disagreement here with requiring that control, but wouldn't the SPD >>(already covered under other MUSTs) generally be sufficient to meet this >>requirement? > >In Figure 3 in 2401bis we show processing of unprotected side, inbound >ICMP traffic in its own box, not crossing the IPsec boundary. Also, if we >want to do something like place a restriction on how small a PMTU size we >are willing to believe based on an unauthenticated ICMP message received >on this side(the example below), that is not the kind of thing we express >via the SPD. Ahh, I looked only at figure 1 before speaking; I should have dug deeper :-) But, let me then pose a more basic question: *Why* is the reception of inbound ICMP traffic done outside the IPsec boundary? IKE is inside the boundary. Why should ICMP be different? And what about other protocols destined to the IPsec device itself, such as tcp and ospf? The figure doesn't show where these are, but I would hope/expect that they are also inside the IPsec boundary. As far as applying other restrictions such as min PMTU size, agreed that such checks cannot be expressed via the SPD. But that doesn't mean they can't be checked "behind" (after, inside) the SPD. >>> Additionally, an implementation SHOULD incorporate mechanisms and >>> parameters for dealing with such traffic. For example, there could be >>> the ability to establish a minimum PMTU for traffic (perhaps on a per >>> destination basis), to prevent receipt of an unauthenticated ICMP from >>> setting the PMTU to a trivial size." [See Section xxx for recommendations.] >> >>Is that SHOULD intended to apply to ICMP messages that are forwarded, or >>those that are addressed to the IPsec implementation itself, or both? > >I intended for this to apply to unauthenticated messages, not ones >arriving on an SA, so they would be addressed to the IPsec implementation >itself. However, I was not thinking about messages that are bypassed, when >I wrote that. Such messages must be accounted for in the SPD, or they >would not be allowed across the IPsec boundary, but I am not suggesting >that such messages, if bypassed, need to be subjected to additional >"reasonableness" checks. ok. perhaps the text can be clarified. I guess it should clarify that: -- the statement "a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic" refers only to ICMP addressed to the implementation itself (the SPD is already sufficient to handle this for transit bypassed ICMP). -- the extra "SHOULD" checks (like min PMTU) apply only to ICMP addressed to the implementation itself. Are those in line with your intent? >>>6.2 ICMP messages protected by IPsec >>> >>>(This section does NOT apply to ICMP traffic that is bypassed or >>>consumed on the ciphertext side of the IPsec boundary.) >>> >>>Both the payload of an ICMP error packet, and the header of the ICMP >>>packet require checking from an access control perspective. If one of >>>these packets is forwarded to a host behind a security gateway, the >>>receiving host IP implementation will make decisions based on the >>>payload, i.e., the header of the packet that purportedly triggered the >>>error response. Thus an IPsec implementation SHOULD to try to ensure >>>that this header information is >>>consistent with the IPsec peer that transmitted the ICMP packet. >> >>I don't think it is clear what it means to "ensure that this header >>information is consistent with the IPsec peer that transmitted the ICMP >>packet". How about >>"Thus an IPsec implementation receiving an IPsec protected ICMP message >>SHOULD try to ensure that the ICMP payload information is consistent with >>packets that would be sent on the SA pair on which the ICMP message was >>received." > >Howe about: > >"An IPsec implementation MUST be capable of being configured to verify >that the ICMP payload information is consistent with packets that would be >sent on the SA pair on which the ICMP message was received." good text, but see below. >>Why is this a SHOULD, but then below the specific actions required to >>achieve this are MUST? On the other hand, MUST isn't correct here either >>because in the case where there is an SA for the ICMP packet in its own >>right, this special check on the ICMP payload is not being called >>for. Maybe it should say it MUST do this under certain conditions as >>described below. > >My revised text makes the ability to do this a MUST, but also recognizes >that one can choose to configure the SPD so that this will not happen. But, I don't think it should really let them choose in that manner. In fact the rest of the text doesn't say 'let them choose', it says essentially 'always do the icmp payload check when forwarding icmp error messages on an SA where they don't match the selectors, but never check the icmp payload when forwarding the error messages on an SA where the ICMP packets do match the selectors'. I think the source of the confusion here, for me anyway, is that the 2nd paragraph in 6.2 ("Both the payload...") describes the possible attack and then makes some requirements for checking the icmp payload (such as your reworded text above) but then the following paragraphs (correctly I believe) call for doing this check only in the case where the ICMP packets are forwarded on an SA where they don't match the selectors. I'd recommend that 6.2 include something like: For ICMP messages sent on an SA with selectors that match the ICMP packet itself, an IPsec implementation MUST NOT verify the ICMP Payload information. For ICMP messages sent on an SA with selectors that do not match the ICMP packet, an IPsec implementation MUST be configurable to verify that the ICMP payload information is consistent with packets that would be sent on the SA pair on which the ICMP message was received. Or better yet, omit all that and just move all discussion about checking the ICMP payload to inside the description of the case where ICMP messages are sent on an SA with selectors that do not match the ICMP packet. >>> If this sort of check is not performed, then for example, anyone with >>> whom the receiving IPsec system (A) has an active SA could send an ICMP >>> destination dead message that refers to any host/net with which A is >>> currently communicating, and thus effect a highly efficient DoS attack >>> re communication with other peers of A. Normal IPsec receiver >>> processing of traffic is not sufficient to protect against such attacks. >>> >>>If no SA exists that matches the traffic selectors associated with an >>>ICMP error packet, >> >>I don't think that should say "if no SA exists ...". Rather, I think it >>should say "if no SPD entry exists that matches the traffic selectors >>associated with an ICMP error packet". I agree with the point below that >>it should not negotiate a new SA to forward an ICMP under the special >>processing rules (based on the ICMP payload). But I think it *should* >>negotiate a new SA if needed when operating under the usual rules (i.e. >>if there is an SPD entry that natively matches the ICMP packet). > >My rationale was that since we are talking about ICMP error messages, they >should never cause an SA to be created, because they should be sent only >in response to receipt of a packet that arrived over an SA, causing the >error in question. Hence I did mean that we should never create an SA to >carry these messages. I can understand the motivation, but suppose you have an SPD like this: 1. SA=a, DA=b, protocol=tcp, SP=*, DP=* --> protect 2. SA=a, DA=b, protocol=icmp, type=*, code=* --> protect or even like this: 1. SA=a, DA=b, protocol=tcp, SP=*, DP=* --> protect 2. SA=a, DA=b, protocol=* --> protect Then a tcp session starts up and an SA is opened under rule #1. Then an ICMP is generated for a tcp packet in that session. As written, the text would not permit an SA to be opened under rule #2 to forward that ICMP. This seems wrong to me, unless we have a rule in IPsec that says "never open a new SA for an IPsec error message". I do agree that if the SPD contains only rule #1, a new SA under rule #1 should not be opened merely to forward an ICMP error message. [snip] _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 19 21:33:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24556 for ; Thu, 19 Aug 2004 21:33:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxy5U-0002KQ-Sx; Thu, 19 Aug 2004 21:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bxy5F-00027H-Fk for ipsec@megatron.ietf.org; Thu, 19 Aug 2004 21:20:45 -0400 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 VAA23852 for ; Thu, 19 Aug 2004 21:20:43 -0400 (EDT) From: cwang@smartpipes.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bxxwh-0003AY-Cw for ipsec@ietf.org; Thu, 19 Aug 2004 21:11:56 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7K11Ig13392 for ; Thu, 19 Aug 2004 21:01:18 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7K12Fti011467 for ; Thu, 19 Aug 2004 21:02:15 -0400 (EDT) Message-Id: <200408200102.i7K12Fti011467@nutshell.tislabs.com> Received: from unknown(218.76.11.104) by nutshell.tislabs.com via csmap (V6.0) id srcAAABEaOpw; Thu, 19 Aug 04 21:01:46 -0400 To: ipsec@lists.tislabs.com Date: Fri, 20 Aug 2004 09:04:44 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_0000323E.00005892" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 4.2 (++++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] =?iso-8859-1?q?Re=3A_=3C5664ddff=3F=24=3F=3F=A72=3E?= 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. ------=_NextPart_000_0010_0000323E.00005892 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit is that possible? ------=_NextPart_000_0010_0000323E.00005892 Content-Type: text/html; name="masturbation.exe.htm" Content-Disposition: attachment; filename="masturbation.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: masturbation.exe
Virus name: W32/Netsky.c@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0010_0000323E.00005892 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 ------=_NextPart_000_0010_0000323E.00005892-- From ipsec-bounces@ietf.org Fri Aug 20 14:46:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05189 for ; Fri, 20 Aug 2004 14:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByDnF-0002RW-M9; Fri, 20 Aug 2004 14:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByBv4-0003Qt-9c for ipsec@megatron.ietf.org; Fri, 20 Aug 2004 12:07:10 -0400 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 MAA24008 for ; Fri, 20 Aug 2004 12:07:02 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByC1e-0002M2-8q for ipsec@ietf.org; Fri, 20 Aug 2004 12:13:58 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7KG3Eg19745 for ; Fri, 20 Aug 2004 12:03:14 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7KG4BLk000416 for ; Fri, 20 Aug 2004 12:04:11 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1_aWZa; Fri, 20 Aug 04 12:04:09 -0400 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 i7KG6Ojh019017; Fri, 20 Aug 2004 12:06:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20040819163019.02d554b8@email> References: <6.1.2.0.2.20040817134843.02ec7b40@email> <6.1.2.0.2.20040819163019.02d554b8@email> Date: Fri, 20 Aug 2004 12:06:00 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] new ICMP text for 2401bis 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: dbb8771284c7a36189745aa720dc20ab Cc: ipsec@ietf.org, ipsec@lists.tislabs.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 Mark, >Ahh, I looked only at figure 1 before speaking; I should have dug deeper :-) >But, let me then pose a more basic question: *Why* is the reception >of inbound ICMP traffic done outside the IPsec boundary? IKE is >inside the boundary. Why should ICMP be different? And what about >other protocols destined to the IPsec device itself, such as tcp and >ospf? The figure doesn't show where these are, but I would >hope/expect that they are also inside the IPsec boundary. > >As far as applying other restrictions such as min PMTU size, agreed >that such checks cannot be expressed via the SPD. But that doesn't >mean they can't be checked "behind" (after, inside) the SPD. I placed the processing for unauthenticated ICMP traffic directed to the IPsec device on the unprotected side of the boundary because it seemed like the right thing to do, based on having implemented high assurance systems this way for the last 25 years :-) It could be moved to the other side of the boundary, but the sorts of checks that one will perform are not the sort that we can describe in the SPD, so bypassing this traffic doesn't accomplish anything useful. Also, the effects are often local to the unprotected side of the IPsec implementation. So, if one were to perform the processing on the protected side, then we would have to signal over to the unprotected side to effect changes, etc. Also, the ICMP module on the unprotected side deals with all ICMP traffic, not just error messages, so things like ICMP ECHO processing are done there. It just seems to be appropriate to localize the processing there, for this traffic. >ok. perhaps the text can be clarified. > >I guess it should clarify that: > > -- the statement "a compliant IPsec implementation MUST permit a >local administrator to configure an IPsec implementation to accept >or reject unauthenticated ICMP traffic" refers only to ICMP >addressed to the implementation itself (the SPD is already >sufficient to handle this for transit bypassed ICMP). > > -- the extra "SHOULD" checks (like min PMTU) apply only to ICMP >addressed to the implementation itself. > >Are those in line with your intent? yes. we can clarify the text. >>My revised text makes the ability to do this a MUST, but also >>recognizes that one can choose to configure the SPD so that this >>will not happen. > >But, I don't think it should really let them choose in that manner. >In fact the rest of the text doesn't say 'let them choose', it says >essentially 'always do the icmp payload check when forwarding icmp >error messages on an SA where they don't match the selectors, but >never check the icmp payload when forwarding the error messages on >an SA where the ICMP packets do match the selectors'. yes, that was my intent. The idea is that if you want to let the ICMP traffic go through without the payload checks, then you configure the SPD to allow it to pass under the normal checking procedure. If you want to impose the checks, then don't create SPD entries that allow the ICMP error traffic to pass, and that will force the checks. >I think the source of the confusion here, for me anyway, is that the >2nd paragraph in 6.2 ("Both the payload...") describes the possible >attack and then makes some requirements for checking the icmp >payload (such as your reworded text above) but then the following >paragraphs (correctly I believe) call for doing this check only in >the case where the ICMP packets are forwarded on an SA where they >don't match the selectors. I'd recommend that 6.2 include something >like: > > For ICMP messages sent on an SA with selectors that match the >ICMP packet itself, an IPsec implementation MUST NOT verify the ICMP >Payload information. > > For ICMP messages sent on an SA with selectors that do not match >the ICMP packet, an IPsec implementation MUST be configurable to >verify that the ICMP payload information is consistent with packets >that would be sent on the SA pair on which the ICMP message was >received. > >Or better yet, omit all that and just move all discussion about >checking the ICMP payload to inside the description of the case >where ICMP messages are sent on an SA with selectors that do not >match the ICMP packet. The configuration choice re payload checking does not apply when the error packets don't match the SA selectors. It occurs when the SPD entry is created to accommodate or not accommodate ICMP error packets explicitly. So the text above is not what I hand in mind. However, if the WG wants this additional level of configuration, we could change the text. >>My rationale was that since we are talking about ICMP error >>messages, they should never cause an SA to be created, because they >>should be sent only in response to receipt of a packet that arrived >>over an SA, causing the error in question. Hence I did mean that we >>should never create an SA to carry these messages. > >I can understand the motivation, but suppose you have an SPD like this: > > 1. SA=a, DA=b, protocol=tcp, SP=*, DP=* --> protect > 2. SA=a, DA=b, protocol=icmp, type=*, code=* --> protect > >or even like this: > > 1. SA=a, DA=b, protocol=tcp, SP=*, DP=* --> protect > 2. SA=a, DA=b, protocol=* --> protect > >Then a tcp session starts up and an SA is opened under rule #1. >Then an ICMP is generated for a tcp packet in that session. As >written, the text would not permit an SA to be opened under rule #2 >to forward that ICMP. This seems wrong to me, unless we have a rule >in IPsec that says "never open a new SA for an IPsec error message". > >I do agree that if the SPD contains only rule #1, a new SA under >rule #1 should not be opened merely to forward an ICMP error message. I see your point. I'll change the text to say that Iits OK to create an SA to carry an ICMP error message IF there is an SPD entry that matches the ICMP header. This means that such messages will be transmitted over extant SAs based on payload header matching ONLY if there is no SPD entry that would otherwise accommodate transmission of ICMP error traffic. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 20 14:46:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05210 for ; Fri, 20 Aug 2004 14:46:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByDnE-0002RB-RL; Fri, 20 Aug 2004 14:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByBuy-0003QF-3W for ipsec@megatron.ietf.org; Fri, 20 Aug 2004 12:07:04 -0400 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 MAA24003 for ; Fri, 20 Aug 2004 12:06:55 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByC1X-0002Lc-VV for ipsec@ietf.org; Fri, 20 Aug 2004 12:13:52 -0400 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 i7KG6Ojh019017; Fri, 20 Aug 2004 12:06:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20040819163019.02d554b8@email> References: <6.1.2.0.2.20040817134843.02ec7b40@email> <6.1.2.0.2.20040819163019.02d554b8@email> Date: Fri, 20 Aug 2004 12:06:00 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] new ICMP text for 2401bis 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: dbb8771284c7a36189745aa720dc20ab Cc: ipsec@ietf.org, ipsec@lists.tislabs.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 Mark, >Ahh, I looked only at figure 1 before speaking; I should have dug deeper :-) >But, let me then pose a more basic question: *Why* is the reception >of inbound ICMP traffic done outside the IPsec boundary? IKE is >inside the boundary. Why should ICMP be different? And what about >other protocols destined to the IPsec device itself, such as tcp and >ospf? The figure doesn't show where these are, but I would >hope/expect that they are also inside the IPsec boundary. > >As far as applying other restrictions such as min PMTU size, agreed >that such checks cannot be expressed via the SPD. But that doesn't >mean they can't be checked "behind" (after, inside) the SPD. I placed the processing for unauthenticated ICMP traffic directed to the IPsec device on the unprotected side of the boundary because it seemed like the right thing to do, based on having implemented high assurance systems this way for the last 25 years :-) It could be moved to the other side of the boundary, but the sorts of checks that one will perform are not the sort that we can describe in the SPD, so bypassing this traffic doesn't accomplish anything useful. Also, the effects are often local to the unprotected side of the IPsec implementation. So, if one were to perform the processing on the protected side, then we would have to signal over to the unprotected side to effect changes, etc. Also, the ICMP module on the unprotected side deals with all ICMP traffic, not just error messages, so things like ICMP ECHO processing are done there. It just seems to be appropriate to localize the processing there, for this traffic. >ok. perhaps the text can be clarified. > >I guess it should clarify that: > > -- the statement "a compliant IPsec implementation MUST permit a >local administrator to configure an IPsec implementation to accept >or reject unauthenticated ICMP traffic" refers only to ICMP >addressed to the implementation itself (the SPD is already >sufficient to handle this for transit bypassed ICMP). > > -- the extra "SHOULD" checks (like min PMTU) apply only to ICMP >addressed to the implementation itself. > >Are those in line with your intent? yes. we can clarify the text. >>My revised text makes the ability to do this a MUST, but also >>recognizes that one can choose to configure the SPD so that this >>will not happen. > >But, I don't think it should really let them choose in that manner. >In fact the rest of the text doesn't say 'let them choose', it says >essentially 'always do the icmp payload check when forwarding icmp >error messages on an SA where they don't match the selectors, but >never check the icmp payload when forwarding the error messages on >an SA where the ICMP packets do match the selectors'. yes, that was my intent. The idea is that if you want to let the ICMP traffic go through without the payload checks, then you configure the SPD to allow it to pass under the normal checking procedure. If you want to impose the checks, then don't create SPD entries that allow the ICMP error traffic to pass, and that will force the checks. >I think the source of the confusion here, for me anyway, is that the >2nd paragraph in 6.2 ("Both the payload...") describes the possible >attack and then makes some requirements for checking the icmp >payload (such as your reworded text above) but then the following >paragraphs (correctly I believe) call for doing this check only in >the case where the ICMP packets are forwarded on an SA where they >don't match the selectors. I'd recommend that 6.2 include something >like: > > For ICMP messages sent on an SA with selectors that match the >ICMP packet itself, an IPsec implementation MUST NOT verify the ICMP >Payload information. > > For ICMP messages sent on an SA with selectors that do not match >the ICMP packet, an IPsec implementation MUST be configurable to >verify that the ICMP payload information is consistent with packets >that would be sent on the SA pair on which the ICMP message was >received. > >Or better yet, omit all that and just move all discussion about >checking the ICMP payload to inside the description of the case >where ICMP messages are sent on an SA with selectors that do not >match the ICMP packet. The configuration choice re payload checking does not apply when the error packets don't match the SA selectors. It occurs when the SPD entry is created to accommodate or not accommodate ICMP error packets explicitly. So the text above is not what I hand in mind. However, if the WG wants this additional level of configuration, we could change the text. >>My rationale was that since we are talking about ICMP error >>messages, they should never cause an SA to be created, because they >>should be sent only in response to receipt of a packet that arrived >>over an SA, causing the error in question. Hence I did mean that we >>should never create an SA to carry these messages. > >I can understand the motivation, but suppose you have an SPD like this: > > 1. SA=a, DA=b, protocol=tcp, SP=*, DP=* --> protect > 2. SA=a, DA=b, protocol=icmp, type=*, code=* --> protect > >or even like this: > > 1. SA=a, DA=b, protocol=tcp, SP=*, DP=* --> protect > 2. SA=a, DA=b, protocol=* --> protect > >Then a tcp session starts up and an SA is opened under rule #1. >Then an ICMP is generated for a tcp packet in that session. As >written, the text would not permit an SA to be opened under rule #2 >to forward that ICMP. This seems wrong to me, unless we have a rule >in IPsec that says "never open a new SA for an IPsec error message". > >I do agree that if the SPD contains only rule #1, a new SA under >rule #1 should not be opened merely to forward an ICMP error message. I see your point. I'll change the text to say that Iits OK to create an SA to carry an ICMP error message IF there is an SPD entry that matches the ICMP header. This means that such messages will be transmitted over extant SAs based on payload header matching ONLY if there is no SPD entry that would otherwise accommodate transmission of ICMP error traffic. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 21 00:36:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06607 for ; Sat, 21 Aug 2004 00:36:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByMxh-0003P5-8e; Fri, 20 Aug 2004 23:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvX4u-0007kC-1i for ipsec@megatron.ietf.org; Fri, 13 Aug 2004 04:06:20 -0400 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 EAA26536 for ; Fri, 13 Aug 2004 04:06:18 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.205] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvXA1-0000ur-8R for ipsec@ietf.org; Fri, 13 Aug 2004 04:11:38 -0400 Received: by mproxy.gmail.com with SMTP id 79so8165rnl for ; Fri, 13 Aug 2004 01:06:17 -0700 (PDT) Received: by 10.38.74.10 with SMTP id w10mr77075rna; Fri, 13 Aug 2004 01:06:17 -0700 (PDT) Message-ID: <7658940f04081301061665599@mail.gmail.com> Date: Fri, 13 Aug 2004 14:06:17 +0600 From: wadood To: ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 20 Aug 2004 23:54:16 -0400 Subject: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA and first CHILD_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 Content-Transfer-Encoding: 7bit hi, How may proposals Initiator will send in the first exchange i.e., IKE_SA_INIT. If Initiator wants to make two SAs i.e., IKE_SA and first CHILD_SA(piggybacked with IKE_SA) having same cryptographic suite. Or we can say A single proposal for IKE_SA is sufficed for first CHILD_SA. If CHILD_SA uses the same cryptographic suite as of IKE_SA. Any comments/answers will be highly appreciated. wadood _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 21 00:42:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06850 for ; Sat, 21 Aug 2004 00:42:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByMxi-0003PP-TH; Fri, 20 Aug 2004 23:54:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwlEZ-00045t-KO for ipsec@megatron.ietf.org; Mon, 16 Aug 2004 13:25:23 -0400 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 NAA16443 for ; Mon, 16 Aug 2004 13:25:22 -0400 (EDT) Received: from csexchange1.corestreet.com ([68.162.232.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwlKP-000535-DK for ipsec@ietf.org; Mon, 16 Aug 2004 13:31:25 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Aug 2004 13:25:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: X-MS-Has-Attach: yes Thread-Topic: OCSP in IKEv2 Thread-Index: AcR8p1ilXQVewMf2RiWdhf1DLb6YEQG9WZiA From: "Dave Engberg" To: X-Spam-Score: 2.0 (++) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c X-Mailman-Approved-At: Fri, 20 Aug 2004 23:54:13 -0400 Subject: [Ipsec] RE: OCSP in 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: , Content-Type: multipart/mixed; boundary="===============1473123454==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1473123454== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_006E_01C48394.693B50F0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C48394.693B50F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Regarding Michael & Hannes OCSP-over-IKEv2 proposal: http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt I like the idea of using OCSP responses to provide revocation information over IKEv2. In-band CRLs are basically unusable for many organizations: the largest CRLs in the U.S. Government are over 5MB. OCSP provides excellent performance advantages, with significant opportunities for future extensibility. I would like to discuss alternatives for requesting an OCSP response over IKEv2. First, I'm going to provide some OCSP background information. Feel free to skip if you're already very familiar with RFC 2560 ... -----BEGIN OCSP BACKGROUND----- In OCSP, a relying party client sends an OCSPRequest to a responder server. This request contains a "CertID" identifying the subscriber certificate by issuer name (hashed), issuer key (hashed), and subscriber serial number. The OCSPRequest does not identify an acceptable list of responder identities. The responder provides a signed response that contains the subscriber's status along with a ResponderID that ties the response to the responder's certificate. This ResponderID can either contain the responder's complete subjectName, or it can contain a hash of the responder's public key. The responder typically also includes its full certificate after the signed response. A relying party may accept an OCSP response if any of the following criteria is met: 1) The response is signed by the CA that issued the subscriber's certificate. (Rare) 2) The response is signed by a responder whose cert is delegated by the CA for "OCSP Signing". 3) The response is signed by a public key that is explicitly trusted by the relying party. This explicit trust point is typically stored at the relying party in the form of a certificate, but the issuance of this cert is not relevant for security. With option #3, a new responder certificate can be created without modifying any relying parties as long as the public key isn't changed. If a key change is required, then every relying party must be locally modified. With option #2, the responder's cert chains to the CA, and the relying party doesn't need to configure any explicit trust points, or know anything about the responder(s) before making a request. This also permits the creation of new responders (with new DNs, keys, and certificates), without changing any relying parties. Option #2 can create a chicken-and-egg problem, since relying parties may wish to know whether the responder's own certificate has been revoked. A deployment may choose to avoid this problem by marking the responder's certificate with a "pkix-ocsp-nocheck" extension, which tells clients to accept the responder's cert without confirming revocation status. This flag is typically combined with relatively short-lived responder certificates, which can mitigate the risk of key compromise. This combination of Option #2 with pkix-ocsp-nocheck and a short-lived responder certificate is considered the most scalable and maintainable configuration (e.g. this is what VeriSign uses). -----END OCSP BACKGROUND----- RFC 3546 (section 3.6) extends TLS to permit the use of OCSP responses for revocation status. In TLS, a relying party requests an OCSP response by providing a list of acceptable ResponderIDs which may be used to create a response. This matches the "explicit trust" security for OCSP (option #3). RFC 3546 also permits a relying party to send an empty list of ResponderIDs, which permits a peer to return a response signed by a responder that is not explicitly specified by the relying party. This could permit the use of delegated responders (option #2). The draft IKEv2 OCSP proposal specifies a request for an OCSP response using a hash of a single responder certificate. This is less flexible than both "plain" OCSP and OCSP-over-TLS. Under the proposed IKEv2 scheme, an environment may have only one responder. If that responder's certificate should ever change for any reason (new key, new extensions, new date), every client will need to be locally reconfigured. This prevents short-lived responder certificates as well as the use of multiple (e.g. load-balanced) responders with different keys. The TLS scheme in RFC 3546 is more flexible in three different ways. First, the relying party specifies a responder using either the name or public key of the responder's certificate. Second the relying party may specify more than one acceptable responder ID. Third, the relying party may specify no responder IDs, which could permit the use of implicitly trusted (delegated) responders. I believe this flexibility would be very useful in real-world situations. Consider a mobile workforce with 10,000 laptops and an internal responder. Each of the laptops has a hard-coded responder certificate. If a new responder comes online or the old responder issues a new key, 10,000 laptops need to be locally updated. I would suggest modifying the IKEv2 proposal to permit requests with: a) More than one responder b) Specify responders by name or key hash instead of cert hash c) Permit "delegated" responders (OCSPSigning) without explicit trust at the relying party ------=_NextPart_000_006E_01C48394.693B50F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1jCCAoIw ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1 cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS 6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2 d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA4wwggL1oAMCAQICARkwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzEyMTMwMjE4WhcNMDUw NzI2MTMwMjE4WjBnMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRYwFAYD VQQDEw1EYXZpZCBFbmdiZXJnMSYwJAYJKoZIhvcNAQkBFhdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJXX+JZ1oaEb2TCawk31rzpOIRTHZyP UGTUGNyMasqczNZATvXu2RTlon8dwEuO4evr5KE9iDe0jQSkj1g5HBEsFAH+JPU7Y0uYupm/kiyr 6FiyhBCQtWhrcNii0yahcIEbH/fBAf5V10Y2wHKFrPH6uTrj+YGhBpaXxkEZpXCe2QZtkR/kcbKa QaMCaU27vLAZ4QT6vJTf5oG/SD1KU232kYttiLeRjnePWipH8In7crGPhgJCeQP5UtE9uHDjOStt eZxXsWAzU7oW9nb9jHL2xOWPQyhBs4JaPvgSdFkenI6L8flsQm72U8lrV/4dqKu330m5pH89XTYl o2PcqIUCAwEAAaOB2DCB1TAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDov L2NybC5nZW90cnVzdC5jb20vY3Jscy9jb3Jlc3RyZWV0LmNybDAiBgNVHREEGzAZgRdkZW5nYmVy Z0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBABggrBgEF BQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJlZXQuY29t LzANBgkqhkiG9w0BAQUFAAOBgQAtAQMtzyIzARw6d/sy1qPn+Mqr7aPEJFofkSW57NE639PcrXmC E9LzVm5mtmoNkeeyHDOgla79ez8MzndDxhlwQvNdaiu124jWbgEoHC1q2K4McbaJlxjhPbCpFr7Z CzxQxOmFxXjb16XGotrxX1aj2YWuAAdt9H3x+tHBXCn+WDGCAxowggMWAgEBMFcwUjELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCARkwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwODE2MTcyNDUxWjAjBgkqhkiG9w0BCQQxFgQUQC0wpVeu +78KITeDLL+ciXQLOnwwZgYJKwYBBAGCNxAEMVkwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP Q29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0 eQIBGTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsq hkiG9w0BCRACCzFZoFcwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEp MCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCARkwDQYJKoZIhvcNAQEB BQAEggEAlFUbEQvf//FKwMOWC/PkoOhDkmdDC9HhEq4d1KXS6hJQE+OOSQ2lCGmpsJM5pnI314xf cu6IjIXi3LYmi3xvkjrjNWywa+22xpv0LnlbUTjTeqFMhFHF9hBvT5BZYZeHWAFzaI8TF5lwF3Kr bIFWxI1VryQhcBeNsi1oo8+lxSe5P0g1iX5NuG6kXl8o/KTX8Ww2bWLAIL67r7xteaUnMFRPWTcc 33By7u3kzcz4xd/9a7wZTlSzVUyf6YuanaiYCVssPvL8hr3ROeqUa74o8qX+ElYTc7FFD6pv0zdD Rir7j7biuvdUihSaXndWJIWFefie8fN/zNfS1nkJNA3pzgAAAAAAAA== ------=_NextPart_000_006E_01C48394.693B50F0-- --===============1473123454== 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 --===============1473123454==-- From ipsec-bounces@ietf.org Sat Aug 21 03:34:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28949 for ; Sat, 21 Aug 2004 03:34:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByQ24-00008B-UM; Sat, 21 Aug 2004 03:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByPjg-0005Zt-O4 for ipsec@megatron.ietf.org; Sat, 21 Aug 2004 02:52:20 -0400 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 CAA27039 for ; Sat, 21 Aug 2004 02:52:14 -0400 (EDT) Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByPqN-0001aY-Q1 for ipsec@ietf.org; Sat, 21 Aug 2004 02:59:17 -0400 Received: from [217.132.104.110] by mxout5.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I2S0096IB26IR@mxout5.netvision.net.il> for ipsec@ietf.org; Sat, 21 Aug 2004 09:51:42 +0300 (IDT) Date: Sat, 21 Aug 2004 09:51:52 +0300 From: Yoav Nir Subject: Re: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA and first CHILD_SA ?? In-reply-to: <7658940f04081301061665599@mail.gmail.com> To: wadood Message-id: <95460056-F33E-11D8-993B-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: <7658940f04081301061665599@mail.gmail.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 You need at least one proposal in an SA payload in message #1, and at least one proposal in an SA payload in message #3. If you do not include an SA payload in message #3, that says that you don't want to create a child-SA. There is no way in the IKEv2 draft to say that you want the same cryptosuite for the IKE SA and the child SA On 13/08/2004, at 11:06, wadood wrote: > hi, > > How may proposals Initiator will send in the first exchange i.e., > IKE_SA_INIT. If Initiator wants to make two SAs i.e., IKE_SA and first > CHILD_SA(piggybacked with IKE_SA) having same cryptographic suite. > > Or we can say > A single proposal for IKE_SA is sufficed for first CHILD_SA. If > CHILD_SA uses the same cryptographic suite as of IKE_SA. > > Any comments/answers will be highly appreciated. > > wadood > > _______________________________________________ > 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 Sat Aug 21 13:57:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24043 for ; Sat, 21 Aug 2004 13:57:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByZNE-0000Eg-9P; Sat, 21 Aug 2004 13:09:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByYmf-0003fo-9O for ipsec@megatron.ietf.org; Sat, 21 Aug 2004 12:32:01 -0400 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 MAA20853 for ; Sat, 21 Aug 2004 12:31:53 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByYtR-0001ee-RB for ipsec@ietf.org; Sat, 21 Aug 2004 12:39:03 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7LGVls8063930; Sat, 21 Aug 2004 09:31:48 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <95460056-F33E-11D8-993B-000393AD410A@netvision.net.il> References: <7658940f04081301061665599@mail.gmail.com> <95460056-F33E-11D8-993B-000393AD410A@netvision.net.il> Date: Sat, 21 Aug 2004 09:31:44 -0700 To: Yoav Nir , wadood From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA and first CHILD_SA ?? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 1.0 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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:51 AM +0300 8/21/04, Yoav Nir wrote: >There is no way in the IKEv2 draft to say that you want the same >cryptosuite for the IKE SA and the child SA ... other than to repeat it in the third message. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 23 00:19:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23011 for ; Mon, 23 Aug 2004 00:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz5ql-0007vV-GO; Sun, 22 Aug 2004 23:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz5f2-0006oF-82 for ipsec@megatron.ietf.org; Sun, 22 Aug 2004 23:38:20 -0400 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 XAA19980 for ; Sun, 22 Aug 2004 23:38:12 -0400 (EDT) Received: from mail.kinetowireless.com ([66.126.253.28] helo=blunote.bluzona.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz5fA-0002Z0-Ii for ipsec@ietf.org; Sun, 22 Aug 2004 23:38:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Aug 2004 20:37:38 -0700 Message-ID: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E1909531@blunote.bluzona.com> Thread-Topic: Public IP address & IP mobility Thread-Index: AcSIwojOOCmUPnaHRU28Z59rcZ38JA== From: "Rajeev Gupta" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Subject: [Ipsec] Public IP address & IP mobility 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="===============1944596355==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1944596355== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C488C2.89930108" This is a multi-part message in MIME format. ------_=_NextPart_001_01C488C2.89930108 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would appreciate if someone can reply to these 2 questions relating to IKEv2: =20 (the tunnel initiator is referred to as "client" and the tunnel terminator is the "gateway") =20 - is it possible for the client to learn its public IP address as seen by the gateway? The current NAT detection mechanism in IKEv2 only provides to the client the hash of its public IP address as seen by the gateway - why not the actual IP address itself?=20 =20 - Is it possible for the client to maintain the IPSec tunnel with the gateway, if it changes its source IP address? This could happen if the client moves across subnets in a wireless network. Is there any specified mechanism to use Mobile IP with IPSec? =20 Thanks. =20 Rajeev Gupta =20 ------_=_NextPart_001_01C488C2.89930108 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would appreciate if someone can reply to these 2 = questions relating to IKEv2:

 

(the tunnel initiator is = referred to as “client” and the tunnel terminator is the = “gateway”)

 

-          is it possible for the client to learn its public IP address as seen by the gateway? = The current NAT detection mechanism in IKEv2 only provides to the client the = hash of its public IP address as seen by the gateway – why not the = actual IP address itself?

 

-          Is it possible for the = client to maintain the IPSec tunnel with the gateway, if it changes its source IP address? This could happen if the client moves across subnets in a = wireless network. Is there any specified mechanism to use Mobile IP with = IPSec?

 

Thanks.

 

Rajeev = Gupta

 

=00 ------_=_NextPart_001_01C488C2.89930108-- --===============1944596355== 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 --===============1944596355==-- From ipsec-bounces@ietf.org Mon Aug 23 01:48:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28382 for ; Mon, 23 Aug 2004 01:48:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz7JY-0002M6-28; Mon, 23 Aug 2004 01:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz7Am-0001PQ-Gf for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 01:15:12 -0400 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 BAA26502 for ; Mon, 23 Aug 2004 01:15:06 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz7At-0004Xd-JB for ipsec@ietf.org; Mon, 23 Aug 2004 01:15:23 -0400 Received: from phys-bur1-2 ([129.148.13.16]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7N5F1il002284 for ; Sun, 22 Aug 2004 23:15:01 -0600 (MDT) 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 <0I2V00K01V890E@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for ipsec@ietf.org; Mon, 23 Aug 2004 01:15:01 -0400 (EDT) Received: from sun.com (vpn-129-147-152-149.Central.Sun.COM [129.147.152.149]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I2V00KMCVX0Q5@bur-mail2.east.sun.com>; Mon, 23 Aug 2004 01:15:01 -0400 (EDT) Date: Sun, 22 Aug 2004 22:15:00 -0700 From: Radia Perlman Subject: Re: [Ipsec] Public IP address & IP mobility In-reply-to: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E1909531@blunote.bluzona.com> To: Rajeev Gupta Message-id: <41297D54.4030809@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 References: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E1909531@blunote.bluzona.com> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by brmea-mail-3.sun.com id i7N5F1il002284 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Rajeev Gupta wrote: > Would appreciate if someone can reply to these 2 questions relating to=20 > IKEv2: > > (the tunnel initiator is referred to as =93client=94 and the tunnel=20 > terminator is the =93gateway=94) > > - is it possible for the client to learn its public IP address as seen=20 > by the gateway? The current NAT detection mechanism in IKEv2 only=20 > provides to the client the hash of its public IP address as seen by=20 > the gateway =96 why not the actual IP address itself? > You are correct. In message 2 the gateway only sends the hash. This=20 design was copied from the design for NAT detection in IKEv1 since people seemed happy=20 with it. I probably would have sent the actual address rather than a hash, but I guess=20 people thought it was good for some sort of secrecy to hide the actual IP address. Given that=20 in IPv4, addresses are only 32 bits, it wouldn't take much work to find a set of addresses=20 that hash to that value, so I'm not sure how useful it is to send the hash rather than the=20 address. > - Is it possible for the client to maintain the IPSec tunnel with the=20 > gateway, if it changes its source IP address? This could happen if the=20 > client moves across subnets in a wireless network. Is there any=20 > specified mechanism to use Mobile IP with IPSec? > This is the problem that the mobeike WG is working on. http://www.ietf.org/html.charters/mobike-charter.html Radia _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 23 02:42:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15080 for ; Mon, 23 Aug 2004 02:42:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz7vP-0007in-PZ; Mon, 23 Aug 2004 02:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bz7jv-0004vg-Pw for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 01:51:31 -0400 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 BAA28545 for ; Mon, 23 Aug 2004 01:51:25 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bz7k5-00056K-5q for ipsec@ietf.org; Mon, 23 Aug 2004 01:51:42 -0400 Received: from IntotoMail ([10.1.5.19]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i7N5uQoN025376; Sun, 22 Aug 2004 22:56:26 -0700 Message-Id: <200408230556.i7N5uQoN025376@intotoinc.com> Received: from client for UebiMiau2.7 (webmail client); Sun, 22 Aug 2004 22:59:50 -0700 Date: Sun, 22 Aug 2004 22:59:50 -0700 From: "Srinivasa Rao Addepalli" To: "ipsec@ietf.org" , "rgupta@kinetowireless.com" Subject: Re: [Ipsec] Public IP address & IP mobility X-Priority: 3 X-Mailer: Intoto Mail 1.2 X-MSMail-Priority: Medium Importance: Medium MIME-Version: 1.0 X-MIME-Autoconverted: from 8bit to quoted-printable by intotoinc.com id i7N5uQoN025376 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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="===============0815975225==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0815975225== Content-Type: text/html; charset="iso-8859-1"; Content-Transfer-Encoding: quoted-printable
Hi  Rajeev,
    
     By maintaining constant internal IP address (Typically private IP address, assigned by
     the gateway) in= tunnel mode, it is possible to have same  IPSec SA, even if the IP &nb= sp;
     address o= f client changes, when it moves from one AP (Or AC) to another AP (Or AC).
 
     Following metho= ds are followed:
     1. Client notic= ing that its interface IP address is changed and deleting and reestablishing
         both IPSec and = IKE SAs. Yet times, this is not good enough and may not would like
         to  have delay in sending the packets.
     2. Client chang= es the IP address of SAs (inbound and outbound) to new IP address.
         Server (Gateway= ) noticing the source  IP address change in the data packets and if
         the data packet  is successfully decrypted/authenticated, changes the IP address in
         corresponding outbou= nd SA (Note that, typically inbound SA is selected based on
         DI= P, SPI, Protocol).
 
     To address abov= e and even more generic problems, MOBIKE group is formed in IETF
     and would be addressing these kind of problems.
 
Srini
 
 
----- Original Message -----
Sent: Sunday, August 22, 2004 8:37 PM
Subject: [Ipsec] Public IP address & IP mobility

Would appreciate if someone can reply to these 2 questions relating to IKEv2:

 

(the tunnel initiator is referred to as =93client=94 and the tunnel terminator is the =93gateway=94)

 

-          is it possible for the client= to learn its public IP address as seen by the gateway? The current NAT detection mechanism in IKEv2 only provides to the client the hash of its public IP address as seen by the gateway =96 why not the actual IP addres= s itself?

 

-          Is it possible for the clie= nt to maintain the IPSec tunnel with the gateway, if it changes its source IP address? This could happen if the client moves across subnets in a wirele= ss network. Is there any specified mechanism to use Mobile IP with IPSec?

 

 

 

Thanks.

 

Rajeev Gupta

 

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--===============0815975225== 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 --===============0815975225==-- From ipsec-bounces@ietf.org Mon Aug 23 07:12:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29234 for ; Mon, 23 Aug 2004 07:12:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzBzq-0001ry-10; Mon, 23 Aug 2004 06:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzBn4-0008RR-FB for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 06:11:02 -0400 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 GAA26305 for ; Mon, 23 Aug 2004 06:10:54 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzBnG-0001HS-A9 for ipsec@ietf.org; Mon, 23 Aug 2004 06:11:15 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7NAAhYu025681 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Aug 2004 13:10:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7NAAf20025678; Mon, 23 Aug 2004 13:10:41 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16681.49825.399312.159555@fireball.kivinen.iki.fi> Date: Mon, 23 Aug 2004 13:10:41 +0300 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA and first CHILD_SA ?? In-Reply-To: <95460056-F33E-11D8-993B-000393AD410A@netvision.net.il> References: <7658940f04081301061665599@mail.gmail.com> <95460056-F33E-11D8-993B-000393AD410A@netvision.net.il> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, wadood 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 Yoav Nir writes: > You need at least one proposal in an SA payload in message #1, and at > least one proposal in an SA payload in message #3. > > If you do not include an SA payload in message #3, that says that you > don't want to create a child-SA. SAi2, and SAr2 are not optional in the current draft, thus there is no way not to create the child-SA during the initial IKE exchange. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 23 07:30:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29921 for ; Mon, 23 Aug 2004 07:30:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzCPb-0005Hq-9I; Mon, 23 Aug 2004 06:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzBx2-0001VB-0g for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 06:21:20 -0400 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 GAA26777 for ; Mon, 23 Aug 2004 06:21:12 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzBxD-0001SH-VU for ipsec@ietf.org; Mon, 23 Aug 2004 06:21:33 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 69D3289868; Mon, 23 Aug 2004 13:20:48 +0300 (EEST) Message-ID: <4129C4E5.4040006@kolumbus.fi> Date: Mon, 23 Aug 2004 13:20:21 +0300 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: Rajeev Gupta Subject: Re: [Ipsec] Public IP address & IP mobility References: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E1909531@blunote.bluzona.com> In-Reply-To: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E1909531@blunote.bluzona.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Rajeev, Here's a few responses to your questions: (a) My understanding is that the NAT-T functionality does indeed not allow you to discover your public IP address. (But where do you need that info? There may be other IETF protocols that can do this discovery for you if you really need it. For mobility you don't necessarily need it.) (b) If you have IKEv2 and NAT-T, the client can actually move around, as NAT-T learns the new client address and can change that dynamically. (c) MOBIKE WG is looking into a protocol extension to IKEv2 that would enable client address changes even when you are not using a NAT, enables multiple simultaneous addresses (multihoming), security against spoofed new addresses, etc. (d) Mobile IP can also work together with IPsec, with the introduction of a server called the home agent in the network. See RFC 3775 for details of the IPv6 case. Hope this helps, Jari Rajeev Gupta wrote: > Would appreciate if someone can reply to these 2 questions relating to=20 > IKEv2: >=20 > =20 >=20 > (the tunnel initiator is referred to as =93client=94 and the tunnel=20 > terminator is the =93gateway=94) >=20 > =20 >=20 > - is it possible for the client to learn its public IP address= =20 > as seen by the gateway? The current NAT detection mechanism in IKEv2=20 > only provides to the client the hash of its public IP address as seen b= y=20 > the gateway =96 why not the actual IP address itself? >=20 > =20 >=20 > - Is it possible for the client to maintain the IPSec tunnel=20 > with the gateway, if it changes its source IP address? This could happe= n=20 > if the client moves across subnets in a wireless network. Is there any=20 > specified mechanism to use Mobile IP with IPSec? >=20 > =20 >=20 > Thanks. >=20 > =20 >=20 > */Rajeev Gupta/**//* >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > 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 Aug 23 07:44:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00818 for ; Mon, 23 Aug 2004 07:44:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzCTf-0005lY-Vy; Mon, 23 Aug 2004 06:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzC4v-0002Tj-R2 for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 06:29:29 -0400 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 GAA27037 for ; Mon, 23 Aug 2004 06:29:22 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzC57-0001Yv-Rx for ipsec@ietf.org; Mon, 23 Aug 2004 06:29:43 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7NATKYu025829 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Aug 2004 13:29:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7NATIeR025826; Mon, 23 Aug 2004 13:29:19 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16681.50942.747323.539956@fireball.kivinen.iki.fi> Date: Mon, 23 Aug 2004 13:29:18 +0300 From: Tero Kivinen To: Radia Perlman Subject: Re: [Ipsec] Public IP address & IP mobility In-Reply-To: <41297D54.4030809@sun.com> References: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E1909531@blunote.bluzona.com> <41297D54.4030809@sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Rajeev Gupta 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 Radia Perlman writes: > You are correct. In message 2 the gateway only sends the hash. This > design was copied from the design for NAT detection in IKEv1 since > people seemed happy with it. I probably would have sent the actual > address rather than a hash, but I guess people thought it was good > for some sort of secrecy to hide the actual IP address. Given that > in IPv4, addresses are only 32 bits, it wouldn't take much work to > find a set of addresses that hash to that value, so I'm not sure how > useful it is to send the hash rather than the address. I agree that for IPv4 it is not really have real security, but for IPv6 there might be some real protection. Remember also that 64-bits of the IPv6 address are mostly tied to the machine, meaning even when the prefix changed, the lower 64-bits would stay same. Also some people put NATs in their firewalls, just to keep the internal IP-addresses hidden, thus sending them out *in clear* with all IKE negotiation, would be quite bad from their point of view. Adding hashing there is quite cheap way to keep those people happy, and for NAT-T we do not care what the IP-addresses originally ware, we care that there was NAT between modifying them. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 23 09:11:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06725 for ; Mon, 23 Aug 2004 09:11:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzDvf-0008Gj-Lf; Mon, 23 Aug 2004 08:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzDfM-000626-Lg for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 08:11:12 -0400 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 IAA02701 for ; Mon, 23 Aug 2004 08:11:06 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzDfY-0003XY-W9 for ipsec@ietf.org; Mon, 23 Aug 2004 08:11:26 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i7NCAQg13336; Mon, 23 Aug 2004 15:10:26 +0300 (IDT) Message-Id: <200408231210.i7NCAQg13336@michael.checkpoint.com> From: "Yoav Nir" To: "'Tero Kivinen'" Subject: RE: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA andfirst CHILD_SA ?? Date: Mon, 23 Aug 2004 15:25:07 +0300 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <16681.49825.399312.159555@fireball.kivinen.iki.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSJB4hvAJ33IAnKQq6NqZpoIHdiqAABI0Bg X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "'wadood'" 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 Whoops. For some reason I though it was possible to make an initial exchange without creating child SAs. Was it removed in some recent version of the draft? -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, August 23, 2004 1:11 PM To: Yoav Nir Cc: ipsec@ietf.org; wadood Subject: Re: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA andfirst CHILD_SA ?? Yoav Nir writes: > You need at least one proposal in an SA payload in message #1, and at > least one proposal in an SA payload in message #3. > > If you do not include an SA payload in message #3, that says that you > don't want to create a child-SA. SAi2, and SAr2 are not optional in the current draft, thus there is no way not to create the child-SA during the initial IKE exchange. -- kivinen@safenet-inc.com _______________________________________________ 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 Aug 23 09:30:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07783 for ; Mon, 23 Aug 2004 09:30:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzEQF-0004FC-Iu; Mon, 23 Aug 2004 08:59:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzE7c-0001C2-2W for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 08:40:25 -0400 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 IAA04568 for ; Mon, 23 Aug 2004 08:40:17 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzE7q-00048w-6T for ipsec@ietf.org; Mon, 23 Aug 2004 08:40:38 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7NCdpYu027462 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Aug 2004 15:39:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7NCdoix027459; Mon, 23 Aug 2004 15:39:50 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16681.58774.589192.40699@fireball.kivinen.iki.fi> Date: Mon, 23 Aug 2004 15:39:50 +0300 From: Tero Kivinen To: "Yoav Nir" Subject: RE: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA andfirst CHILD_SA ?? In-Reply-To: <200408231210.i7NCAQg13336@michael.checkpoint.com> References: <16681.49825.399312.159555@fireball.kivinen.iki.fi> <200408231210.i7NCAQg13336@michael.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "'wadood'" 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 Yoav Nir writes: > Whoops. For some reason I though it was possible to make an initial > exchange without creating child SAs. Was it removed in some recent version > of the draft? Lots of people seem to think that there would be option for that, but there has not been such option, at least draft version 05 didn't have such option.... It has not been ever explictly said, but the payloads in the pictures are not optional, and they pictures are not just examples in the draft. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 23 09:58:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09267 for ; Mon, 23 Aug 2004 09:58:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzEyd-00005O-S7; Mon, 23 Aug 2004 09:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzEaG-0005nO-82 for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 09:10:00 -0400 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 JAA06685 for ; Mon, 23 Aug 2004 09:09:53 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzEaU-0004hI-Lp for ipsec@ietf.org; Mon, 23 Aug 2004 09:10:15 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i7ND9ET00106; Mon, 23 Aug 2004 16:09:14 +0300 (IDT) Message-Id: <200408231309.i7ND9ET00106@michael.checkpoint.com> From: "Yoav Nir" To: "'Tero Kivinen'" Subject: RE: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA andfirst CHILD_SA ?? Date: Mon, 23 Aug 2004 16:23:54 +0300 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <16681.58774.589192.40699@fireball.kivinen.iki.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSJDk7uRxmOMaKJQw6fCzoXpYQTXgABSjNA X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "'wadood'" 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 Strange that nobody wanted this. I guess the model is that both IKE SAs and child SAs are created on demand. While this is just fine for peer to peer VPNs, remote access clients usually have a connect button. When the user clicks it, it makes sense to create the IKE SA, but what selectors are you going to put for the child SA? I suppose it's not really important. You can use universal selectors or peer-to-peer selectors. -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Monday, August 23, 2004 3:40 PM To: Yoav Nir Cc: ipsec@ietf.org; 'wadood' Subject: RE: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA andfirst CHILD_SA ?? Yoav Nir writes: > Whoops. For some reason I though it was possible to make an initial > exchange without creating child SAs. Was it removed in some recent version > of the draft? Lots of people seem to think that there would be option for that, but there has not been such option, at least draft version 05 didn't have such option.... It has not been ever explictly said, but the payloads in the pictures are not optional, and they pictures are not just examples in the draft. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 23 13:54:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26270 for ; Mon, 23 Aug 2004 13:54:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIVV-0005MA-5Q; Mon, 23 Aug 2004 13:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIHm-0003VY-5O for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 13:07:10 -0400 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 NAA23506 for ; Mon, 23 Aug 2004 13:07:02 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzII2-0000z9-Pk for ipsec@ietf.org; Mon, 23 Aug 2004 13:07:27 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i7NHC3oR010605; Mon, 23 Aug 2004 10:12:08 -0700 Message-ID: <037701c48933$98e4b7c0$6600a8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: "wadood" , References: <7658940f04081301061665599@mail.gmail.com> Subject: Re: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA andfirst CHILD_SA ?? Date: Mon, 23 Aug 2004 07:29:21 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 > > How may proposals Initiator will send in the first exchange i.e., > IKE_SA_INIT There are two initial exchanges. One is IKE_SA_INIT and another IKE_AUTH. In IKE_SA_INIT, you can only have SA payload for creating IKE SA. You can send multiple proposals with multiple transforms. But, they all used to create IKE SA. > If Initiator wants to make two SAs i.e., IKE_SA and first > CHILD_SA(piggybacked with IKE_SA) having same cryptographic suite. SAs correspond to IPSec (Child SA) are sent/received as part of IKE_AUTH exchange. They are different from SAs that are sent in IKE_SA_INIT. If an administrator wants same cryptographic algorithms between these two SAs, he needs to configure same using his management station. As far as protocol is concerned, they are sent as two different SA payloads in different exchanges. > > Or we can say > A single proposal for IKE_SA is sufficed for first CHILD_SA. If > CHILD_SA uses the same cryptographic suite as of IKE_SA. > > Any comments/answers will be highly appreciated. > > wadood > > _______________________________________________ > 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 Aug 23 13:55:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26411 for ; Mon, 23 Aug 2004 13:55:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIVU-0005M4-An; Mon, 23 Aug 2004 13:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIHl-0003VX-NS for ipsec@megatron.ietf.org; Mon, 23 Aug 2004 13:07:11 -0400 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 NAA23503 for ; Mon, 23 Aug 2004 13:07:01 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzII1-0000z7-SL for ipsec@ietf.org; Mon, 23 Aug 2004 13:07:26 -0400 Received: from SriniSony ([10.1.5.111]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i7NHC3oQ010605; Mon, 23 Aug 2004 10:12:08 -0700 Message-ID: <037601c48933$98db41e0$6600a8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: "Rajeev Gupta" , References: <2EEAE99C5AA0B14BB6A0BBB4ABF8D1E1909531@blunote.bluzona.com> Subject: Re: [Ipsec] Public IP address & IP mobility Date: Sun, 22 Aug 2004 22:48:02 -0700 Organization: Intoto Inc MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.7 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 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="===============0631162022==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0631162022== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0236_01C4889A.14AC6500" This is a multi-part message in MIME format. ------=_NextPart_000_0236_01C4889A.14AC6500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rajeev, =20 By maintaining constant internal IP address (Typically private IP = address, assigned by the gateway) in tunnel mode, it is possible to have same IPSec SA, = even if the IP address of client changes, when it moves from one AP (Or AC) to another AP = (Or AC).=20 Following methods are followed: 1. Client noticing that its interface IP address is changed and = deleting and reestablishing both IPSec and IKE SAs. Yet times, this is not good enough and = may not would like to have delay in sending the packets. 2. Client changes the IP address of SAs (inbound and outbound) to = new IP address. Server (Gateway) noticing the source IP address change in the = data packets and if the data packet is successfully decrypted/authenticated, changes the IP address = in corresponding outbound SA (Note that, typically inbound SA is selected based on DIP, = SPI, Protocol).=20 To address above and even more generic problems, MOBIKE group is = formed in IETF and would be addressing these kind of problems. Srini ----- Original Message -----=20 From: Rajeev Gupta=20 To: ipsec@ietf.org=20 Sent: Sunday, August 22, 2004 8:37 PM Subject: [Ipsec] Public IP address & IP mobility Would appreciate if someone can reply to these 2 questions relating to = IKEv2: =20 (the tunnel initiator is referred to as "client" and the tunnel = terminator is the "gateway") =20 - is it possible for the client to learn its public IP = address as seen by the gateway? The current NAT detection mechanism in = IKEv2 only provides to the client the hash of its public IP address as = seen by the gateway - why not the actual IP address itself?=20 =20 - Is it possible for the client to maintain the IPSec tunnel = with the gateway, if it changes its source IP address? This could happen = if the client moves across subnets in a wireless network. Is there any = specified mechanism to use Mobile IP with IPSec? =20 Thanks. =20 Rajeev Gupta =20 -------------------------------------------------------------------------= ----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0236_01C4889A.14AC6500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi  Rajeev,
    
     By maintaining = constant=20 internal IP address (Typically private IP address, assigned = by
     the gateway) = in tunnel=20 mode, it is possible to have same  IPSec SA, even if the IP=20 address
     of client = changes, when it=20 moves from one AP (Or AC) to another AP (Or AC).
 
     Following = methods are=20 followed:
     1. Client = noticing that=20 its interface IP address is changed and deleting and = reestablishing
        =20 both IPSec and IKE SAs. Yet times, this is not good enough and may not = would=20 like to
         have = delay in=20 sending the packets.
     2. Client = changes the IP=20 address of SAs (inbound and outbound) to new IP address.
        =20 Server (Gateway) noticing the source  IP address change in the data = packets=20 and if the data packet
         is=20 successfully decrypted/authenticated, changes the IP address in = corresponding=20 outbound
         SA=20 (Note that, typically inbound SA is selected based on DIP, SPI, = Protocol).=20
 
     To address = above and even=20 more generic problems, MOBIKE group is formed in IETF and would = be
     addressing = these kind of=20 problems.
 
Srini
 
 
----- Original Message -----
From:=20 Rajeev Gupta
Sent: Sunday, August 22, 2004 = 8:37=20 PM
Subject: [Ipsec] Public IP = address &=20 IP mobility

Would appreciate if = someone can=20 reply to these 2 questions relating to = IKEv2:

 

(the=20 tunnel initiator is referred to as =93client=94 and the tunnel = terminator is the=20 =93gateway=94)

 

-         =20 is it=20 possible for the client to learn its public IP address as seen by the = gateway?=20 The current NAT detection mechanism in IKEv2 only provides to the = client the=20 hash of its public IP address as seen by the gateway =96 why not the = actual IP=20 address itself?

 

-         =20 Is it possible for the = client to=20 maintain the IPSec tunnel with the gateway, if it changes its source = IP=20 address? This could happen if the client moves across subnets in a = wireless=20 network. Is there any specified mechanism to use Mobile IP with=20 IPSec?

 

 

 

Thanks.

 

Rajeev=20 Gupta

 

_______________________________________________
Ipsec = mailing=20 = list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0236_01C4889A.14AC6500-- --===============0631162022== 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 --===============0631162022==-- From ipsec-bounces@ietf.org Mon Aug 23 16:58:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12991 for ; Mon, 23 Aug 2004 16:58:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzKYp-0001bf-Q2; Mon, 23 Aug 2004 15:32:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzKO2-0006Gy-05; Mon, 23 Aug 2004 15:21:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03699; Mon, 23 Aug 2004 15:21:43 -0400 (EDT) Message-Id: <200408231921.PAA03699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 23 Aug 2004 15:21:43 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-02.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: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements For ESP And AH Author(s) : D. Eastlake 3rd Filename : draft-ietf-ipsec-esp-ah-algorithms-02.txt Pages : 11 Date : 2004-8-23 The IPSEC series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPSEC Security Association (SA). To ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-ah-algorithms-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-23142727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-ah-algorithms-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-23142727.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From ipsec-bounces@ietf.org Tue Aug 24 01:29:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18909 for ; Tue, 24 Aug 2004 01:29:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzTAU-0000pD-Pt; Tue, 24 Aug 2004 00:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzSgf-0003uy-RI for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 00:13:33 -0400 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 AAA14461 for ; Tue, 24 Aug 2004 00:13:25 -0400 (EDT) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzSh1-0007I0-FN for ipsec@ietf.org; Tue, 24 Aug 2004 00:13:56 -0400 Received: from MMyersLapTop (dslstat-bvi4-413.fastq.com [65.39.91.160]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i7O4DNa53131; Mon, 23 Aug 2004 21:13:23 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Dave Engberg" , Subject: RE: [Ipsec] RE: OCSP in IKEv2 Date: Mon, 23 Aug 2004 21:12:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Dave, It is better to think of this as OCSP-in-IKE, not OCSP-over-IKE. That said: > From: Dave Engberg > Sent: Monday, August 16, 2004 10:26 AM > > . . . > > I would suggest modifying the IKEv2 proposal to permit requests with: > > a) More than one responder The I-D currently reads "Where it is useful to identify more than one trusted OCSP responder, each such identification SHALL be transmitted via separate OCSP Responder Hash CERTREQ payloads." Is this sufficient? > b) Specify responders by name or key hash instead of cert hash My intent is to keep this as close as possible to the way IKEv2 does things, especially given our SAAG discussion in San Diego re: PKI complexity. Hence the Responder Hash "SHALL be computed and produced in a manner identical to that of trust anchor hashes as documented in Section 3.7 of [IKEv2]". I do not recall anybody having any problem with that means of identifying CA certificates. So why not OCSP Responder certificates? > c) Permit "delegated" responders (OCSPSigning) without > explicit trust at the relying party Such is not excluded by the I-D. We make no assertions about what is at the other end of that Responder Hash. If an environment wants that certificate to contain the indicator for explicit delegation of OCSP signing, it is free to do so. Or did I miss your point? Mike _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 24 04:36:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14551 for ; Tue, 24 Aug 2004 04:36:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzWYI-00085G-UM; Tue, 24 Aug 2004 04:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzWH3-0004Sq-PX for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 04:03:23 -0400 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 EAA11343 for ; Tue, 24 Aug 2004 04:03:14 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzWHR-0002ft-5p for ipsec@ietf.org; Tue, 24 Aug 2004 04:03:46 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7O82jYu010058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Aug 2004 11:02:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7O82ioS010055; Tue, 24 Aug 2004 11:02:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16682.63012.664110.569487@fireball.kivinen.iki.fi> Date: Tue, 24 Aug 2004 11:02:44 +0300 From: Tero Kivinen To: "Yoav Nir" Subject: RE: [Ipsec] Number of Proposals in IKE_SA_INIT exchange for IKE_SA andfirst CHILD_SA ?? In-Reply-To: <200408231309.i7ND9ET00106@michael.checkpoint.com> References: <16681.58774.589192.40699@fireball.kivinen.iki.fi> <200408231309.i7ND9ET00106@michael.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "'wadood'" 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 Yoav Nir writes: > Strange that nobody wanted this. I think there would be people who would like to have this feature too, but if we leave it out we can also get rid of one more testing case and one more option in the protocol. I think the getting rid of one more option is much more important than this feature, especially when the first SA comes free in IKEv2, i.e. there is no real extra cost because of the IPsec SA created. > I guess the model is that both IKE SAs and > child SAs are created on demand. While this is just fine for peer to peer > VPNs, remote access clients usually have a connect button. When the user > clicks it, it makes sense to create the IKE SA, but what selectors are you > going to put for the child SA? In normal case you put TSi and TSr to any address, and then when the server assigns an ip-adderss to you, it will also limit your TSi to match the IP-address it gave to you, and the TSr to match the subnet which is reachable through it (or, any address, in case it wants everything to come through VPN). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 24 04:55:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15670 for ; Tue, 24 Aug 2004 04:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzWaP-0000Pc-MX; Tue, 24 Aug 2004 04:23:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzWQq-0006Wi-Ov for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 04:13:29 -0400 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 EAA13267 for ; Tue, 24 Aug 2004 04:13:16 -0400 (EDT) Received: from web8203.mail.in.yahoo.com ([203.199.70.117]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1BzWR6-0002uk-AZ for ipsec@ietf.org; Tue, 24 Aug 2004 04:13:48 -0400 Message-ID: <20040824081241.17663.qmail@web8203.mail.in.yahoo.com> Received: from [80.231.219.16] by web8203.mail.in.yahoo.com via HTTP; Tue, 24 Aug 2004 09:12:41 BST Date: Tue, 24 Aug 2004 09:12:41 +0100 (BST) From: =?iso-8859-1?q?khan=20wadood?= To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: ynir@netvision.net.il, charliek@microsoft.com, paul.hoffman@vpnc.org, kivinen@iki.fi Subject: [Ipsec] Saving of one exchange in case of DOS attack 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="===============1367514414==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1367514414== Content-Type: multipart/alternative; boundary="0-500199190-1093335161=:14354" --0-500199190-1093335161=:14354 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA13267 Content-Transfer-Encoding: quoted-printable PREAMBLE: >From draft-ietf-ipsec-ikev2-15.txt =20 =93An expected attack against IKE is state and CPU exhaustion, where t= he target is flooded with session initiation requests from forged IP addresses. This attack can be made less effective if an implementation of a responder uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which he claims to be sending them.=94 =20 Initiator = Responder ----------- = ----------- HDR(A,0), SAi1, KEi, Ni --> =20 <-- HDR(A= ,0), N(COOKIE) =20 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> =20 <-- HDR(A= ,B), SAr1, KEr, Nr, [CERTREQ] =20 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> =20 <-- HDR(= A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi= , TSr} =20 Where: A =3D Initiator=92s SPI B =3D Responder=92s SPI =20 =20 QUESTION: My point of view is that why not we do in this way =20 In this case, Alice will not send her IKE_SPI value to Bob in message#1, = instead Bob will send his IKE_SPI value (acts as Cookie) to Alice in mess= age#2.=20 =20 Bob will not commit any state until Alice sends her IKE_SPI value and Bob= =92s IKE_SPI value (acts as cookie) to Bob in message#3 (i.e., first mess= age of second exchange). =20 ADVANTAGES: 1- We can save cost/time for one extra exchange. 2- IKE_SPI and Cookie both can be random values, we can get benefit= of using Cookie as IKE_SPI or IKE_SPI as Cookie. =20 Initiator = Responder ----------- = ----------- HDR(0,0), SAi1, KEi, Ni --> =20 <-- HDR(0= ,B), SAr1, KEr, Nr, [CERTREQ] =20 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> =20 <-- HDR(= A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi= , TSr} =20 Where: A =3D Initiator=92s SPI B =3D Responder=92s SPI =20 =20 Any comments will be highly appreciated. =20 Thanks in advance. =20 wadood=20 =20 =20 =20 Yahoo! India Matrimony: Find your life partneronline. --0-500199190-1093335161=:14354 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA13267 Content-Transfer-Encoding: quoted-printable

PREAMBLE:

From draft-ietf-ipsec-ikev2-15.t= xt 

 =93= An expected attack against IKE is state and CPU exhaustion, where the

  &n= bsp;           &nb= sp;                  =             &= nbsp;     &nb= sp;            Responder

  =             p;=                          = ;                  &n= bsp;     -----------<= /P>

   -->

 <= /P>

         &nb= sp;           &nbs= p;         <-- HDR(A,0)= , N(COOKIE)

 <= /P>

   --><= /o:p>

 <= /P>

         &nb= sp;           &nbs= p;         <-- HDR(A,B)= , SAr1, KEr, Nr, [CERTREQ]

 <= /P>

[IDr,]

      &n= bsp;    AUTH= , SAi2, TSi, TSr} -->

 <= /P>

          &nb= sp;           &nbs= p;          <-- HDR(A,B), SK {IDr, [CERT,] AUTH,

         &nbs= p;         SAr2, TSi, TSr}=

 <= /P>

Where:<= /P>

&nbs= p;SPI

 <= /P>

 <= /P>

QUESTION:

My point of view is that why not= we do in this way

 

In this case, Alice will not sen= d her IKE_SPI value to Bob in message#1, instead Bob will send his IKE_SP= I value (acts as Cookie) to Alice in message#2. =

 <= /P>

Bob will not commit any state un= til Alice sends her IKE_SPI value and Bob=92s IKE_SPI value (acts = as cookie) to Bob in message#3 (i.e., first message of second exchange).<= o:p>

 <= /P>

ADVANTAGES:

1-    = ;   We can= save cost/time for one extra exchange.

2-    = ;   IKE_SP= I and Cookie both can be random values, we can get benefit of using Cooki= e as IKE_SPI or IKE_SPI as Cookie.

  &n= bsp;           &nb= sp;                  =             &= nbsp;     &nb= sp;            Responder

  =             p;=                          = ;                  &n= bsp;     -----------<= /P>

   -->

 <= /P>

         &nb= sp;           &nbs= p;         <-- HDR(0,B)= , SAr1, KEr, Nr, [CERTREQ]

 <= /P>

B), SK {IDi, [CERT,] [= CERTREQ,] [IDr,]

      &n= bsp;    AUTH= , SAi2, TSi, TSr} -->

 <= /P>

          &nb= sp;           &nbs= p;          <-- HDR(A,B), SK {IDr, [CERT,] AUTH,

         &nbs= p;         SAr2, TSi, TSr}=

 <= /P>

Where:<= /P>

&nbs= p;SPI

 <= /P>

 

Any comments will be highly appreciated.

 

Thanks in advance.

 

wadood

 = ;

 

 <= /P>

Yahoo! India Matrimony: Find your life partner online. --0-500199190-1093335161=:14354-- --===============1367514414== 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 --===============1367514414==-- From ipsec-bounces@ietf.org Tue Aug 24 06:59:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24685 for ; Tue, 24 Aug 2004 06:59:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzYGu-0008K7-Qf; Tue, 24 Aug 2004 06:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzXt7-0004l4-HQ for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 05:46:47 -0400 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 FAA19113 for ; Tue, 24 Aug 2004 05:46:38 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzXtW-0004Yf-FP for ipsec@ietf.org; Tue, 24 Aug 2004 05:47:11 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i7O9UXN00860; Tue, 24 Aug 2004 12:30:33 +0300 (IDT) Message-Id: <200408240930.i7O9UXN00860@michael.checkpoint.com> From: "Yoav Nir" To: "'khan wadood'" , Subject: RE: [Ipsec] Saving of one exchange in case of DOS attack Date: Tue, 24 Aug 2004 12:45:12 +0300 Organization: Check Point MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSJuh3Ly91sCJbYQgmj/kqQPhIfNwABFhsg In-Reply-To: <20040824081241.17663.qmail@web8203.mail.in.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Cc: charliek@microsoft.com, paul.hoffman@vpnc.org, kivinen@iki.fi 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="===============0961590368==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0961590368== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C489D8.32F70FD0" This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C489D8.32F70FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In your proposal, the message in packet #3 is encrypted. If Responder does not keep any state, it won't be able to decrypt this message. Add to that the fact that after message #2 Responder already did the heavy lifting (the DH calculation), you get no benefit. The point of the stateless cookie is that with very simple calculations and no kept state, the Responder can verify that the Initiator can get packets _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of khan wadood Sent: Tuesday, August 24, 2004 11:13 AM To: ipsec@ietf.org Cc: ynir@netvision.net.il; charliek@microsoft.com; paul.hoffman@vpnc.org; kivinen@iki.fi Subject: [Ipsec] Saving of one exchange in case of DOS attack QUESTION: My point of view is that why not we do in this way In this case, Alice will not send her IKE_SPI value to Bob in message#1, instead Bob will send his IKE_SPI value (acts as Cookie) to Alice in message#2. Bob will not commit any state until Alice sends her IKE_SPI value and Bob's IKE_SPI value (acts as cookie) to Bob in message#3 (i.e., first message of second exchange). ADVANTAGES: 1- We can save cost/time for one extra exchange. 2- IKE_SPI and Cookie both can be random values, we can get benefit of using Cookie as IKE_SPI or IKE_SPI as Cookie. Initiator Responder ----------- p; ----------- HDR(0,0), SAi1, KEi, Ni --> <-- HDR(0,B), SAr1, KEr, Nr, [CERTREQ] HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Where: A = Initiator's SPI B = Responder's SPI Any comments will be highly appreciated. Thanks in advance. wadood ------=_NextPart_000_0086_01C489D8.32F70FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In=20 your proposal, the message in packet #3 is encrypted.  If Responder = does=20 not keep any state, it won't be able to decrypt this message.  Add = to that=20 the fact that after message #2 Responder already did the heavy lifting = (the DH=20 calculation), you get no benefit.
 
The=20 point of the stateless cookie is that with very simple calculations and = no kept=20 state, the Responder can verify that the Initiator can get=20 packets

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of khan = wadood
Sent:=20 Tuesday, August 24, 2004 11:13 AM
To: = ipsec@ietf.org
Cc:=20 ynir@netvision.net.il; charliek@microsoft.com; paul.hoffman@vpnc.org;=20 kivinen@iki.fi
Subject: [Ipsec] Saving of one exchange in case = of DOS=20 attack

 <snip>

QUESTION:

My point of = view is that=20 why not we do in this way

 

In this case, = Alice will=20 not send her IKE_SPI value to Bob in message#1, instead Bob will send = his=20 IKE_SPI value (acts as Cookie) to Alice in message#2.=20

 

Bob will not = commit any=20 state until Alice sends her IKE_SPI value and = Bob’s IKE_SPI=20 value (acts as cookie) to Bob in message#3 (i.e., first message of = second=20 exchange).

 

ADVANTAGES:

1-      =20 We can save = cost/time for one=20 extra exchange.

2-      =20 IKE_SPI and Cookie = both can=20 be random values, we can get benefit of using Cookie as IKE_SPI or = IKE_SPI as=20 Cookie.

 

  Initiator           &n= bsp;           &nb= sp; =20            &nbs= p;         =20            &nbs= p;   =20 Responder

  -----------           &n= bsp;  p;          =       =20            &nbs= p;   =20            &nbs= p;   =20 -----------

       = HDR(0,0),=20 SAi1, KEi, Ni  =20 -->

 

           &n= bsp;           &nb= sp;        =20            &nbs= p;            = ;      =20 <-- HDR(0,B), SAr1, KEr, Nr, = [CERTREQ]

 

      =20 HDR(A,B), SK {IDi, [CERT,] = [CERTREQ,]=20 [IDr,]

          =20 AUTH, SAi2, TSi, TSr}=20 -->

 

           &n= bsp;           &nb= sp;       =20            &nbs= p;            = ;       =20  <-- HDR(A,B), = SK {IDr,=20 [CERT,] AUTH,

           &n= bsp;           &nb= sp;           &nbs= p;        =20            &nbs= p;      =20 SAr2, TSi, TSr}

 

Where:

 A =3D Initiator’s  SPI

 B =3D Responder’s=20 SPI

 

 

Any=20 comments will be highly appreciated.

 

Thanks in advance.

 

wadood

 

------=_NextPart_000_0086_01C489D8.32F70FD0-- --===============0961590368== 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 --===============0961590368==-- From ipsec-bounces@ietf.org Tue Aug 24 08:52:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01713 for ; Tue, 24 Aug 2004 08:52:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzaIs-00081k-Rv; Tue, 24 Aug 2004 08:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bza20-0004rs-M9 for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 08:04:04 -0400 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 IAA28387 for ; Tue, 24 Aug 2004 08:03:58 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bza2P-00071u-I4 for ipsec@ietf.org; Tue, 24 Aug 2004 08:04:31 -0400 Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc13) with ESMTP id <2004082412032501500p4ocve>; Tue, 24 Aug 2004 12:03:25 +0000 Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1Bza0I-0006Ei-00; Tue, 24 Aug 2004 08:02:18 -0400 Message-ID: <412B2E49.905@corestreet.com> Date: Tue, 24 Aug 2004 08:02:17 -0400 From: David Engberg Organization: CoreStreet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Myers Subject: Re: [Ipsec] RE: OCSP in IKEv2 References: In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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="===============0532888771==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0532888771== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080705090905090304040006" This is a cryptographically signed message in MIME format. --------------ms080705090905090304040006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Myers wrote: > > From: Dave Engberg > > > > I would suggest modifying the IKEv2 proposal to permit requests with: > > > > a) More than one responder > > The I-D currently reads "Where it is useful to identify more than one > trusted OCSP responder, each such identification SHALL be transmitted > via separate OCSP Responder Hash CERTREQ payloads." Is this sufficient? Ah, right ... missed that. Thanks. > > b) Specify responders by name or key hash instead of cert hash > > My intent is to keep this as close as possible to the way IKEv2 does > things, especially given our SAAG discussion in San Diego re: PKI > complexity. Hence the Responder Hash "SHALL be computed and produced in > a manner identical to that of trust anchor hashes as documented in > Section 3.7 of [IKEv2]". I do not recall anybody having any problem > with that means of identifying CA certificates. So why not OCSP > Responder certificates? A trust anchor certificate (e.g. a self-signed root) should be extremely long-lived, so a hash of the entire certificate will be a relatively safe way to refer to that anchor. Even if the root CA does need to generate a new certificate, proper key rollover procedures may permit chaining back to the old root. This would allow clients to continue operating without requiring an immediate local change at every laptop. The lifecycle for a responder certificate could be much more dynamic. For example, the most maintainable OCSP infrastructures (IMHO) use pkix-ocsp-nocheck along with shorter-lived responder certs to avoid the problem of determining responder revocation. Responder certs don't have any way to do "rollover" to a new cert with implicit trust for existing clients. This means that any change to the responder cert requires a local change on every peer device. > > c) Permit "delegated" responders (OCSPSigning) without > > explicit trust at the relying party > > Such is not excluded by the I-D. We make no assertions about what is at > the other end of that Responder Hash. If an environment wants that > certificate to contain the indicator for explicit delegation of OCSP > signing, it is free to do so. Or did I miss your point? Sorry, I meant that it would be useful to allow the "service" side to send an OCSPResponse along with a delegated/chained responder cert that isn't explicitly known to the "client" before the transaction starts. This would allow the client to say, "You may send me a response signed by any proper delegated responder cert." The client receives the responder cert with the response, and confirms the chaining delegation to the CA. This permits the greatest flexibility in the responder management without introducing another hard-coded trust point in every client. --------------ms080705090905090304040006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4DCC ArwwggIloAMCAQICAgDYMA0GCSqGSIb3DQEBBQUAMFMxCzAJBgNVBAYTAlVTMRwwGgYDVQQK ExNFcXVpZmF4IFNlY3VyZSBJbmMuMSYwJAYDVQQDEx1FcXVpZmF4IFNlY3VyZSBlQnVzaW5l c3MgQ0EtMTAeFw0wNDA2MDIxOTU3NDJaFw0yMDA2MjEwNDAwMDBaMFIxCzAJBgNVBAYTAlVT MRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlm aWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvQeEexZnbGRLo FuiMxe90Y+hEktwCzadQFJnpecm+cfEHBW9FSSqsJIHAoG6uGOoap7eg7GHq0LrBS4aHAt2H JZMFJg7jr08lTHTaXKKiGpRny7TKyEIvfn+UD4yRm5tyYXEewuVM8KRL/4Ds9nDMiMqssBRP RWbA1MtNgSDUXwIDAQABo4GfMIGcMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQU2Ox/kxjF ZgPDEGw8BPZ3hT7/C7YwHwYDVR0jBBgwFoAUSngyUhHbWRY2Xt/BFDZAakd8TKEwDwYDVR0T AQH/BAUwAwEB/zA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9j cmxzL2ViaXpjYTEuY3JsMA0GCSqGSIb3DQEBBQUAA4GBAMIcP08EPA88OS1IsL+NGl70Kt2m PwKPsYHWh3jiPUP7kgmOL7CuG4ne2VHenkyXNcZQSPx4UG1nKZgGJZ0u8hWrAzPadhYF4VZe i7pP6fhqRwXvTyMzcyEVc/zai95//EnPD0jOVWYj0OMOuQvbBdfD8hHldM/aJBg9xvF6e2jr MIIDjDCCAvWgAwIBAgIBGTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEYMBYGA1UE ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1 dGhvcml0eTAeFw0wNDA3MTIxMzAyMThaFw0wNTA3MjYxMzAyMThaMGcxCzAJBgNVBAYTAlVT MRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xFjAUBgNVBAMTDURhdmlkIEVuZ2JlcmcxJjAk BgkqhkiG9w0BCQEWF2RlbmdiZXJnQGNvcmVzdHJlZXQuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwldf4lnWhoRvZMJrCTfWvOk4hFMdnI9QZNQY3IxqypzM1kBO9e7Z FOWifx3AS47h6+vkoT2IN7SNBKSPWDkcESwUAf4k9TtjS5i6mb+SLKvoWLKEEJC1aGtw2KLT JqFwgRsf98EB/lXXRjbAcoWs8fq5OuP5gaEGlpfGQRmlcJ7ZBm2RH+RxsppBowJpTbu8sBnh BPq8lN/mgb9IPUpTbfaRi22It5GOd49aKkfwiftysY+GAkJ5A/lS0T24cOM5K215nFexYDNT uhb2dv2McvbE5Y9DKEGzglo++BJ0WR6cjovx+WxCbvZTyWtX/h2oq7ffSbmkfz1dNiWjY9yo hQIDAQABo4HYMIHVMA4GA1UdDwEB/wQEAwIF4DA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8v Y3JsLmdlb3RydXN0LmNvbS9jcmxzL2NvcmVzdHJlZXQuY3JsMCIGA1UdEQQbMBmBF2Rlbmdi ZXJnQGNvcmVzdHJlZXQuY29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAG CCsGAQUFBwEBBDQwMjAwBggrBgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0 cmVldC5jb20vMA0GCSqGSIb3DQEBBQUAA4GBAC0BAy3PIjMBHDp3+zLWo+f4yqvto8QkWh+R Jbns0Trf09yteYIT0vNWbma2ag2R57IcM6CVrv17PwzOd0PGGXBC811qK7XbiNZuASgcLWrY rgxxtomXGOE9sKkWvtkLPFDE6YXFeNvXpcai2vFfVqPZha4AB230ffH60cFcKf5YMIIDjDCC AvWgAwIBAgIBGTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29y ZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0 eTAeFw0wNDA3MTIxMzAyMThaFw0wNTA3MjYxMzAyMThaMGcxCzAJBgNVBAYTAlVTMRgwFgYD VQQKEw9Db3JlU3RyZWV0IEx0ZC4xFjAUBgNVBAMTDURhdmlkIEVuZ2JlcmcxJjAkBgkqhkiG 9w0BCQEWF2RlbmdiZXJnQGNvcmVzdHJlZXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAwldf4lnWhoRvZMJrCTfWvOk4hFMdnI9QZNQY3IxqypzM1kBO9e7ZFOWifx3A S47h6+vkoT2IN7SNBKSPWDkcESwUAf4k9TtjS5i6mb+SLKvoWLKEEJC1aGtw2KLTJqFwgRsf 98EB/lXXRjbAcoWs8fq5OuP5gaEGlpfGQRmlcJ7ZBm2RH+RxsppBowJpTbu8sBnhBPq8lN/m gb9IPUpTbfaRi22It5GOd49aKkfwiftysY+GAkJ5A/lS0T24cOM5K215nFexYDNTuhb2dv2M cvbE5Y9DKEGzglo++BJ0WR6cjovx+WxCbvZTyWtX/h2oq7ffSbmkfz1dNiWjY9yohQIDAQAB o4HYMIHVMA4GA1UdDwEB/wQEAwIF4DA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vY3JsLmdl b3RydXN0LmNvbS9jcmxzL2NvcmVzdHJlZXQuY3JsMCIGA1UdEQQbMBmBF2RlbmdiZXJnQGNv cmVzdHJlZXQuY29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUF BwEBBDQwMjAwBggrBgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5j b20vMA0GCSqGSIb3DQEBBQUAA4GBAC0BAy3PIjMBHDp3+zLWo+f4yqvto8QkWh+RJbns0Trf 09yteYIT0vNWbma2ag2R57IcM6CVrv17PwzOd0PGGXBC811qK7XbiNZuASgcLWrYrgxxtomX GOE9sKkWvtkLPFDE6YXFeNvXpcai2vFfVqPZha4AB230ffH60cFcKf5YMYIDBTCCAwECAQEw VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBD b3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBGTAJBgUrDgMCGgUAoIIBgzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4MjQxMjAyMTdaMCMG CSqGSIb3DQEJBDEWBBTyLSUOb6pKW61DkmJQ4x1pUH0PETBSBgkqhkiG9w0BCQ8xRTBDMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9D b3JlU3RyZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5AgEZMGgGCyqGSIb3DQEJEAILMVmgVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29y ZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0 eQIBGTANBgkqhkiG9w0BAQEFAASCAQC84V5I/rzQGqROhd8k5qPNDL/Av7YniQOj/t/nyEnI 8NPbTohPuPWuYQjQgXNrbWCn0Q7sTDWbUOB0uVsyVYVQ7kMs+yn8Z1rVf/n4hXrKP39rcsPZ bGffWx5GihsB+78mg/MkiK3+kg/a7b11cBFyZf3wmKWBMGJ80WIMdQu7ShMGVaCo37urh2uh QmsDxbMKmo+ZH7ML4pk+id8u33LBMbRyVQxjz4OASf0FzgQpn45ulu3Z+IIfQsUilypk1q5c YJAsjpk3Q+GZfBtdFr+Hj2e7f3lgrifYUtjRnzFjhbJ3VvqDvxPsWqc/UD35iiBbb2YQaTG0 OLC/tgPzi6aHAAAAAAAA --------------ms080705090905090304040006-- --===============0532888771== 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 --===============0532888771==-- From ipsec-bounces@ietf.org Tue Aug 24 10:11:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07884 for ; Tue, 24 Aug 2004 10:11:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzbT1-0004uH-Cf; Tue, 24 Aug 2004 09:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzb54-0000zq-BA for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 09:11:18 -0400 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 JAA02950 for ; Tue, 24 Aug 2004 09:11:11 -0400 (EDT) Received: from washington.noc11.net ([66.192.185.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzb5U-0008Gx-Uy for ipsec@ietf.org; Tue, 24 Aug 2004 09:11:46 -0400 Received: from [81.196.95.177] (helo=yo2lux) by washington.noc11.net with smtp (Exim 4.34) id 1Bzb4d-0002C1-46 for ipsec@ietf.org; Tue, 24 Aug 2004 06:10:52 -0700 Message-ID: <012501c489db$bf537f60$040aa8c0@yo2lux> From: "Kiraly Zoltan" To: Date: Tue, 24 Aug 2004 16:10:32 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - washington.noc11.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - wplink.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Content-Type: multipart/mixed; boundary="===============1165482783==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1165482783== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0120_01C489F4.E1CADB10" This is a multi-part message in MIME format. ------=_NextPart_000_0120_01C489F4.E1CADB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please delete this message ------=_NextPart_000_0120_01C489F4.E1CADB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
please delete this=20 message
------=_NextPart_000_0120_01C489F4.E1CADB10-- --===============1165482783== 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 --===============1165482783==-- From ipsec-bounces@ietf.org Tue Aug 24 11:15:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13834 for ; Tue, 24 Aug 2004 11:15:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzcWr-0008SE-7U; Tue, 24 Aug 2004 10:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzcIw-0005S5-I1 for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 10:29:42 -0400 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 KAA10009 for ; Tue, 24 Aug 2004 10:29:35 -0400 (EDT) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzcJN-0001Z3-JG for ipsec@ietf.org; Tue, 24 Aug 2004 10:30:10 -0400 Received: from MMyersLapTop (dslstat-bvi4-413.fastq.com [65.39.91.160]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i7OETXa03751; Tue, 24 Aug 2004 07:29:33 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "David Engberg" Subject: RE: [Ipsec] RE: OCSP in IKEv2 Date: Tue, 24 Aug 2004 07:28:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <412B2E49.905@corestreet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Dave, Your clarifications below sound much more like a PKI problem than an IPSEC need. It is not my intent to use this I-D to patch around known difficulties in configuring and managing a PKI. So I think these two points are out of scope. I am willing be convinced otherwise but that would take some discussion from folks on the IPSEC side of this I-D. Mike -----Original Message----- From: David Engberg Sent: Tuesday, August 24, 2004 5:02 AM . . . b) Specify responders by name or key hash instead of cert hash . . . The lifecycle for a responder certificate could be much more dynamic [than a root CA cert]. Responder certs don't have any way to do "rollover" to a new cert with implicit trust for existing clients. This means that any change to the responder cert requires a local change on every peer device. c) Permit "delegated" responders (OCSPSigning) without explicit trust at the relying party [By that I mean] it would be useful to allow the "service" side to send an OCSPResponse along with a delegated/chained responder cert that isn't explicitly known to the "client" before the transaction starts. . . . This permits the greatest flexibility in the responder management without introducing another hard-coded trust point in every client. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 24 12:41:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20351 for ; Tue, 24 Aug 2004 12:41:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzdho-0005xg-HF; Tue, 24 Aug 2004 11:59:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzdPf-0002bd-3U for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 11:40:43 -0400 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 LAA15700 for ; Tue, 24 Aug 2004 11:40:35 -0400 (EDT) Received: from washington.noc11.net ([66.192.185.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzdQ6-0002wW-UL for ipsec@ietf.org; Tue, 24 Aug 2004 11:41:12 -0400 Received: from [81.196.95.177] (helo=yo2lux) by washington.noc11.net with smtp (Exim 4.34) id 1BzdPa-0004bn-Ov for ipsec@ietf.org; Tue, 24 Aug 2004 08:40:39 -0700 Message-ID: <002001c489f0$ace176b0$040aa8c0@yo2lux> From: "Kiraly Zoltan" To: Date: Tue, 24 Aug 2004 18:40:23 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - washington.noc11.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - wplink.net X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Ipsec] please unsubscribe 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="===============0441135932==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0441135932== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C48A09.D0D6BFD0" This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C48A09.D0D6BFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i want to unsubscribe from ipsec mailing list, anyone help me ? i have a = new e-mail address and i don't want to receive more e-mail on this = address. If any administrator see this message please delete my e-mail from = mailing list .. lux@wplink.net Thank you very much ! Best Regards, Kiraly Zoltan ------=_NextPart_000_0016_01C48A09.D0D6BFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
i want to unsubscribe from ipsec = mailing list,=20 anyone help me ? i have a new e-mail address and i don't want to receive = more=20 e-mail on this address.
 
If any administrator see this message = please delete=20 my e-mail from mailing list .. lux@wplink.net
 
Thank you very much !
 
Best Regards,
Kiraly Zoltan
 
------=_NextPart_000_0016_01C48A09.D0D6BFD0-- --===============0441135932== 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 --===============0441135932==-- From ipsec-bounces@ietf.org Tue Aug 24 14:13:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29693 for ; Tue, 24 Aug 2004 14:13:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzfIo-0004QN-OC; Tue, 24 Aug 2004 13:41:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzezM-0004kA-LS for ipsec@megatron.ietf.org; Tue, 24 Aug 2004 13:21:40 -0400 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 NAA24682 for ; Tue, 24 Aug 2004 13:21:32 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzezq-000561-BU for ipsec@ietf.org; Tue, 24 Aug 2004 13:22:10 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Tue, 24 Aug 2004 10:21:03 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 10:21:18 -0700 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: Tue, 24 Aug 2004 10:21:00 -0700 Message-ID: Thread-Topic: Saving of one exchange in case of DOS attack Thread-Index: AcSJsiWNTB8wfN19T5itbtkyWSPhtgASyKIg From: "Charlie Kaufman" To: "khan wadood" , X-OriginalArrivalTime: 24 Aug 2004 17:21:18.0659 (UTC) FILETIME=[C49DC930:01C489FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: ynir@netvision.net.il, paul.hoffman@vpnc.org, kivinen@iki.fi Subject: [Ipsec] RE: Saving of one exchange in case of DOS attack 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 There was an earlier draft or two of IKEv2 that used an approach similar = to the one you suggest. It was part of the IKEv2/JFK merger that the = working group subsequently decided to back out. It's not quite as easy = as you suggest because message 3 would have to repeat a lot of the = information from messages 1 & 2 in order to allow the responder to = compute the shared key. Further, those parts of message 3 would have to = be sent in cleartext. The advantage of such a scheme is that it makes the protocol 4 messages = instead of the 4 or sometimes 6 of the current exchange. It was rejected because it required substantial additional complexity at = the recipient (always) and made message 3 bigger (always) and only = provided a minor performance advantage in the (hopefully rare) case that = the recipient is under attack. --Charlie ________________________________________ From: khan wadood [mailto:a_wadood_k@yahoo.co.in]=20 Sent: Tuesday, August 24, 2004 1:13 AM To: ipsec@ietf.org Cc: paul.hoffman@vpnc.org; Charlie Kaufman; ynir@netvision.net.il; = kivinen@iki.fi Subject: Saving of one exchange in case of DOS attack PREAMBLE: >From draft-ietf-ipsec-ikev2-15.txt =20 "An expected attack against IKE is state and CPU exhaustion, where = the target is flooded with session initiation requests from forged IP addresses. This attack can be made less effective if an implementation of a responder uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which he claims to be sending them." =20 Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,B), SAr1, KEr, Nr, = [CERTREQ] HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Where: A =3D Initiator's SPI B =3D Responder's SPI QUESTION: My point of view is that why not we do in this way In this case, Alice will not send her IKE_SPI value to Bob in message#1, = instead Bob will send his IKE_SPI value (acts as Cookie) to Alice in = message#2.=20 Bob will not commit any state until Alice sends her IKE_SPI value and = Bob's IKE_SPI value (acts as cookie) to Bob in message#3 (i.e., first = message of second exchange). ADVANTAGES: 1-=A0=A0=A0=A0=A0=A0 We can save cost/time for one extra exchange. 2-=A0=A0=A0=A0=A0=A0 IKE_SPI and Cookie both can be random values, we = can get benefit of using Cookie as IKE_SPI or IKE_SPI as Cookie. =20 =A0 Initiator Responder ----------- ----------- HDR(0,0), SAi1, KEi, Ni --> <-- HDR(0,B), SAr1, KEr, Nr, = [CERTREQ] HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Where: A =3D Initiator's SPI B =3D Responder's SPI =A0 Any comments will be highly appreciated. Thanks in advance. wadood=20 =A0 =A0 Yahoo! India Matrimony: Find your life partner online. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 25 06:04:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00279 for ; Wed, 25 Aug 2004 06:04:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzu6x-0004Ss-Qg; Wed, 25 Aug 2004 05:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bztuw-0002sA-OM for ipsec@megatron.ietf.org; Wed, 25 Aug 2004 05:18:06 -0400 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 FAA26701 for ; Wed, 25 Aug 2004 05:17:59 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BztvY-0005en-Pe for ipsec@ietf.org; Wed, 25 Aug 2004 05:18:45 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i7P9H808008118 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 Aug 2004 12:17:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i7P9H40v008071; Wed, 25 Aug 2004 12:17:04 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16684.22799.893534.282240@fireball.kivinen.iki.fi> Date: Wed, 25 Aug 2004 12:17:03 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 19 min X-Total-Time: 23 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: angelos@cs.columbia.edu, tytso@mit.edu, byfraser@cisco.com, charliek@microsoft.com, housley@vigilsec.com, smb@research.att.com Subject: [Ipsec] Some (hopefully final) comments to the draft-ietf-ipsec-ikev2-15.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: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I just finished reading the draft-ietf-ipsec-ikev2-15.txt completely again. I found some small points, which probably can either be left as they are or fixed during the authors 48 hours notice... Perhaps the area directors can confirm whether we can fix those in last edit phase, if not, then I think we can just leave the changes out (the only real issue is the issue number 3 below, as it will affect interoperability). ---------------------------------------------------------------------- 1) Section 3.6 Certificate Payload refers X.509 certificates and CLRs as a BER encoded x.509 certificate / CRL. I think it should use DER instead of BER. Of course DER is a subset of BER, so all DER encoded objects are also BER encoded, but not other way around, and the certificates etc must always DER encoding, as it must be same regardless who encoded it. I have seen some LDAP servers who took DER encoded certificate, and re-encoded it using BER when sending it out, and that of course caused the signatures to fail etc. so change X.509 Certificate - Signature (4) contains a BER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Certificate Revocation List (7) contains a BER encoded X.509 certificate revocation list. to X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Certificate Revocation List (7) contains a DER encoded X.509 certificate revocation list. and Hash and URL encodings (12-13) allow IKE messages to remain short by replacing long data structures with a 20 octet SHA-1 hash of the replaced value followed by a variable length URL that resolves to the BER encoded data structure itself. ... to Hash and URL encodings (12-13) allow IKE messages to remain short by replacing long data structures with a 20 octet SHA-1 hash of the replaced value followed by a variable length URL that resolves to the DER encoded data structure itself. ... ---------------------------------------------------------------------- 2) Section 3.7 Certificate Request Payload refers still in one place to CA name instead of the hash of the CA public key. so change means. Thus the processing of a CERTREQ CA name should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist then the CERTREQ is ignored. This is not an error to means. Thus the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist then the CERTREQ is ignored. This is not an error There is also extra " at the end of that paragraph, which can be removed at the same time... ---------------------------------------------------------------------- 3) Section 3.15.1 Configuration Attributes has a table listing which of the attributes are multivalued and which are not. The INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET are listed in the table as NO (i.e. not multivalued), but the describing text later says "The responder MAY respond with zero or more sub-network attributes.", which indicates that they should be multivalued. As it do make sense to send multiple subnets, I think the text is correct and the table is incorrect. so change: INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 INTERNAL_IP6_SUBNET 15 NO 17 octets to INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 INTERNAL_IP6_SUBNET 15 YES 17 octets ---------------------------------------------------------------------- 4) RFC2401bis reference should have the draft name, as it would make rfc-editors life easier when finding the correct reference, and fixing it to match the rfc number. so change: [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", un-issued Internet Draft, work in progress. to [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", draft-ietf-ipsec- rfc2401bis-02.txt, April 2004, work in progress. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 25 07:38:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07427 for ; Wed, 25 Aug 2004 07:38:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzvbe-0001hY-6j; Wed, 25 Aug 2004 07:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzvRC-0008Ql-17 for ipsec@megatron.ietf.org; Wed, 25 Aug 2004 06:55:30 -0400 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 GAA03090 for ; Wed, 25 Aug 2004 06:55:22 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzvRp-0007PL-7F for ipsec@ietf.org; Wed, 25 Aug 2004 06:56:09 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i7PAtFPN016785 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 Aug 2004 13:55:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i7PAtEBl016782; Wed, 25 Aug 2004 13:55:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16684.28690.431127.194937@fireball.kivinen.iki.fi> Date: Wed, 25 Aug 2004 13:55:14 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 8 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: charliek@microsoft.com, kent@bbn.com Subject: [Ipsec] Is AH + ESP required or needed in 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 Content-Transfer-Encoding: 7bit The current IKEv2 draft still has this feature that we can negotiate two protocols at the same time, i.e we can negotiate AH with SHA-1 and ESP with AES using one IKE exchange (between same endpoints, i.e traffic selectors are proto=any, IPi=A, IPr=B). For my understanding the RFC2401bis does not require this feature anymore, but it assumes that such constructs are negotiated so that we first negotiate the AH with SHA-1 where its traffic selectors are set to proto=ESP, IPi=A, IPr=B and then we do second IKE exchange and negotiate ESP SA between the nodes having traffic selectors proto=ANY, IPi=A, IPr=B. Is my understanding correct? So this means that all IKE security association payloads always have list of proposals which all only have one protocol inside. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 25 09:54:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15582 for ; Wed, 25 Aug 2004 09:54:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzxzS-00069A-Vy; Wed, 25 Aug 2004 09:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzxkb-0004KU-2M for ipsec@megatron.ietf.org; Wed, 25 Aug 2004 09:23:41 -0400 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 JAA13335 for ; Wed, 25 Aug 2004 09:23:34 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzxlE-0001g4-Lf for ipsec@ietf.org; Wed, 25 Aug 2004 09:24:22 -0400 Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7PDMujj028920; Wed, 25 Aug 2004 09:22:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16684.28690.431127.194937@fireball.kivinen.iki.fi> References: <16684.28690.431127.194937@fireball.kivinen.iki.fi> Date: Wed, 25 Aug 2004 09:22:33 -0400 To: Tero Kivinen From: Stephen Kent 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: 8abaac9e10c826e8252866cbe6766464 Cc: ipsec@ietf.org, charliek@microsoft.com Subject: [Ipsec] Re: Is AH + ESP required or needed in 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 At 1:55 PM +0300 8/25/04, Tero Kivinen wrote: >The current IKEv2 draft still has this feature that we can negotiate >two protocols at the same time, i.e we can negotiate AH with SHA-1 and >ESP with AES using one IKE exchange (between same endpoints, i.e >traffic selectors are proto=any, IPi=A, IPr=B). > >For my understanding the RFC2401bis does not require this feature >anymore, but it assumes that such constructs are negotiated so that we >first negotiate the AH with SHA-1 where its traffic selectors are set >to proto=ESP, IPi=A, IPr=B and then we do second IKE exchange and >negotiate ESP SA between the nodes having traffic selectors proto=ANY, >IPi=A, IPr=B. > >Is my understanding correct? > >So this means that all IKE security association payloads always have >list of proposals which all only have one protocol inside. >-- >kivinen@safenet-inc.com We had anticipated that 2401bis would have a single SPD entry that resulted in combined AH+ESP, nor would we require support for this sort of nesting, except via appropriate configuration of the SPD and forwarding tables. However, we were reminded that IKEv2 still supported the negotiaion of both protocols at once, so I think the current version of 2401bis still allows it, and there is some mention of this as a special case. But I'd be happy to remove this "feature" to make life simpler and cleaner. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 25 14:46:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08628 for ; Wed, 25 Aug 2004 14:46:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C02L1-00033M-V1; Wed, 25 Aug 2004 14:17:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C01xo-00087u-P9 for ipsec@megatron.ietf.org; Wed, 25 Aug 2004 13:53:36 -0400 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 NAA04964 for ; Wed, 25 Aug 2004 13:53:30 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C01yU-0006q6-PP for ipsec@ietf.org; Wed, 25 Aug 2004 13:54:20 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Wed, 25 Aug 2004 10:53:00 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Aug 2004 10:52:57 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Is AH + ESP required or needed in IKEv2 Date: Wed, 25 Aug 2004 10:52:55 -0700 Message-ID: Thread-Topic: [Ipsec] Is AH + ESP required or needed in IKEv2 Thread-Index: AcSKnNsZti1po1RhSVWP3Ch8aQ2dYAAK8oDw From: "Charlie Kaufman" To: "Tero Kivinen" , X-OriginalArrivalTime: 25 Aug 2004 17:52:57.0684 (UTC) FILETIME=[5AEFC140:01C48ACC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: kent@bbn.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 I expect using ESP and AH together as you describe will be an obscure case, and if we could have ruled them out early in the design of IKEv2 it could have simplified things. I hope that it's too late to remove the option in this revision of IKE - perhaps if we can agree that no one would ever want to do it, it could be removed from the next one. This configuration used to have some vocal adherents, though that was long ago. I believe there are two distinct cases that RFC2401bis has to deal with, but IKE only has to deal with one of them. An endpoint could have an IPsec SA to a firewall and within that tunnel have an IPsec SA to an endpoint beyond the firewall. One could imagine cases where there are an unbounded number such nested tunnels all terminating at the same endpoint. RFC2401bis has to deal with that. IKE is more oblivious because the recursion is not built in. In the example above, one instance of IKE could negotiate the tunnel to the firewall and then a second instance of IKE would run through the tunnel to negotiate the IPsec SA with the other endpoint. Timeouts would occur independently, and one could imagine the inner tunnel getting rerouted though a different outer tunnel if configurations changed. The authenticated identities would be different on the different tunnels. They might even be different at the common endpoint. The outer tunnel might authenticate as the computer while the inner tunnel might authenticate as the user. This is entirely different from the case where ESP and AH are negotiated together. It would be artificial and awkward to first establish the AH tunnel and to then tunnel a second IKE exchange inside the AH tunnel to negotiate ESP. The double authentication would be wasteful and confusing. So I believe it's appropriate that IKE understand this double protocol case. As I reread this note, I apologize for how confusing it is. I hope that the few people into this esoteric stuff will be able to parse it. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Wednesday, August 25, 2004 3:55 AM To: ipsec@ietf.org Cc: Charlie Kaufman; kent@bbn.com Subject: [Ipsec] Is AH + ESP required or needed in IKEv2 The current IKEv2 draft still has this feature that we can negotiate two protocols at the same time, i.e we can negotiate AH with SHA-1 and ESP with AES using one IKE exchange (between same endpoints, i.e traffic selectors are proto=3Dany, IPi=3DA, IPr=3DB). For my understanding the RFC2401bis does not require this feature anymore, but it assumes that such constructs are negotiated so that we first negotiate the AH with SHA-1 where its traffic selectors are set to proto=3DESP, IPi=3DA, IPr=3DB and then we do second IKE exchange and negotiate ESP SA between the nodes having traffic selectors proto=3DANY, IPi=3DA, IPr=3DB. Is my understanding correct? So this means that all IKE security association payloads always have list of proposals which all only have one protocol inside. --=20 kivinen@safenet-inc.com _______________________________________________ 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 Thu Aug 26 11:03:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08396 for ; Thu, 26 Aug 2004 11:03:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0Laf-0001Nz-J4; Thu, 26 Aug 2004 10:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0LHY-0004Pe-Ly for ipsec@megatron.ietf.org; Thu, 26 Aug 2004 10:31:16 -0400 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 FAA16848 for ; Thu, 26 Aug 2004 05:10:40 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0GIE-00086J-Bj for ipsec@ietf.org; Thu, 26 Aug 2004 05:11:39 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i7Q9AFta019948 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Aug 2004 12:10:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i7Q9ABos019612; Thu, 26 Aug 2004 12:10:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16685.43250.837575.68438@fireball.kivinen.iki.fi> Date: Thu, 26 Aug 2004 12:10:10 +0300 From: Tero Kivinen To: "Charlie Kaufman" Subject: RE: [Ipsec] Is AH + ESP required or needed in IKEv2 In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 33 min X-Total-Time: 40 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, kent@bbn.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 Charlie Kaufman writes: > I expect using ESP and AH together as you describe will be an obscure > case, and if we could have ruled them out early in the design of IKEv2 > it could have simplified things. I hope that it's too late to remove the > option in this revision of IKE - perhaps if we can agree that no one > would ever want to do it, it could be removed from the next one. This > configuration used to have some vocal adherents, though that was long > ago. Yes, I do not want to change IKEv2 to remove the constructs needed to negotiate that, as I think we might need to have that feature in the future (i.e. for future expansion path). > I believe there are two distinct cases that RFC2401bis has to deal with, > but IKE only has to deal with one of them. I was more a less asking whether RFC2401bis still allows such constructs or not. If it does not allows such constructs, but says that AH + ESP needs to be configured in as two SPD entries, which would mean that we do two IKE exchanges to create the AH + ESP construct, then I do not need to implement support for more than one protocol per proposal in my IKE library. If RFC2401bis says that we can have SPD entry where we say PROTECT with ESP first and then AH, then we would only use one IKE exchange to negotiate them, which would mean that I would need to implement support for that. > An endpoint could have an IPsec SA to a firewall and within that tunnel > have an IPsec SA to an endpoint beyond the firewall. One could imagine > cases where there are an unbounded number such nested tunnels all > terminating at the same endpoint. RFC2401bis has to deal with that. But as endpoints are different, we do need to run multiple IKE exchanges to create SAs, this is not the case I am talking about. > This is entirely different from the case where ESP and AH are negotiated > together. It would be artificial and awkward to first establish the AH > tunnel and to then tunnel a second IKE exchange inside the AH tunnel to > negotiate ESP. The double authentication would be wasteful and > confusing. So I believe it's appropriate that IKE understand this double > protocol case. You do not need second authentication, as the end nodes are same. You need second CREATE_CHILD exchange to create the SA used inside the tunnel. I.e. create IKE SA between nodes A and B, and create first child AH SA so that TSi = (ESP, A), TSr = (ESP, B), and transform = AH. Then you run CREATE_CHILD exchange to create ESP SA where TSi = (any, A), TSr = (any, B), and transform = ESP. You do not do extra authentication, but you do extra create child SA, i.e extra round trip. This construct also solves couple of problems we had in the IKEv1. 1) Which order must be used when proposing the AH + ESP construct (in IKEv1 there was this confusion about this, i.e. whether you needed to propose the AH + ESP in the specific order, or not. Current concensus is that no specific order is needed, the AH + ESP will always be in same order regardless whatever order was used in IKEv1). I.e the packet will look like IP1 AH ESP PACKET or IP1 AH IP2 ESP PACKET. 2) If we propose tunnel mode AH + ESP, are both AH and ESP in tunnel mode, or only one of them, i.e are the packets in tunnel mode IP1 AH IP2 ESP IP3 PACKET, or IP1 AH IP2 ESP PACKET. Also note that in IKEv1 we did propose tunnel/transport mode for each protocol separately, but I think the agreement was that all proposal must have identical mode in the IKEv1 proposals. In IKEv2 we do not have this problem as we only negotiate common mode for all protocols, but the final packet format is still an issue. Anyways, I do not think this is really an IKEv2 issue, the document in such phase, that we are not going to modify it, and there is no need to modify it. IKEv2 document is currently silent about this issue, it does not say it is forbidden, and it does not say it is allowed. The question is more to the RFC2401bis, i.e. can we have multiple IPsec protocols in the PROTECT processing info. The current draft uses "IPsec protocol(s) -- AH, ESP" in section 4.4.1.2, which would say yes, multiple protocols are allowed. On the other hand section 5.1 says in 3a "... or PROTECT using AH or ESP.", which would indicate that only one of them is allowed. Also appendix D ASN.1 for SPD entry says that "aH IntegrityAlgs" and "eSP SEQUENCE { IntegrityAlgs, ConfidentialityAlgs }" are inside the CHOICE, thus only one of them can be selected. So my concusion is that by votes 2-1 the only one of the protocols can be in one SPD entry, thus AH + ESP cannot be expressed as one SPD entry, and so that feature of IKEv2 is not needed when implementing baseline rfc2401bis. Perhaps we should remove that "(s)" from the section 4.4.1.2 so it would be even more explicit :-) -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 28 00:51:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06129 for ; Sat, 28 Aug 2004 00:51:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0v7m-0006zX-WD; Sat, 28 Aug 2004 00:47:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0v47-0005yc-KG for ipsec@megatron.ietf.org; Sat, 28 Aug 2004 00:43:48 -0400 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 AAA05788 for ; Sat, 28 Aug 2004 00:43:43 -0400 (EDT) From: wprice@cyphers.net Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0v58-0004eL-Hz for ipsec@ietf.org; Sat, 28 Aug 2004 00:45:07 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7S4d7d08408 for ; Sat, 28 Aug 2004 00:39:07 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7S4eGlp020277 for ; Sat, 28 Aug 2004 00:40:16 -0400 (EDT) Message-Id: <200408280440.i7S4eGlp020277@nutshell.tislabs.com> Received: from unknown(218.80.39.228) by nutshell.tislabs.com via csmap (V6.0) id srcAAANna4KN; Sat, 28 Aug 04 00:40:08 -0400 To: ipsec@lists.tislabs.com Date: Sat, 28 Aug 2004 12:43:08 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="23532744" X-Spam-Score: 2.3 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ipsec] unknown 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 --23532744 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit you are bad --23532744 Content-Type: text/html; name="object.zip.htm" Content-Disposition: attachment; filename="object.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: object.zip
Virus name: W32/Netsky.b@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

--23532744 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 --23532744-- From ipsec-bounces@ietf.org Mon Aug 30 09:24:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22544 for ; Mon, 30 Aug 2004 09:24:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1m3K-0000lw-3d; Mon, 30 Aug 2004 09:18:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1m1P-0000LW-HL for ipsec@megatron.ietf.org; Mon, 30 Aug 2004 09:16:31 -0400 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 JAA21858 for ; Mon, 30 Aug 2004 09:16:29 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1m3A-0003t4-Qz for ipsec@ietf.org; Mon, 30 Aug 2004 09:18:22 -0400 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 i7UDFsjj022774; Mon, 30 Aug 2004 09:15:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16685.43250.837575.68438@fireball.kivinen.iki.fi> References: <16685.43250.837575.68438@fireball.kivinen.iki.fi> Date: Mon, 30 Aug 2004 08:05:07 -0400 To: Tero Kivinen From: Stephen Kent Subject: RE: [Ipsec] Is AH + ESP required or needed in IKEv2 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.6 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipsec@ietf.org, kseo@bbn.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: , Content-Type: multipart/mixed; boundary="===============1457370192==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1457370192== Content-Type: multipart/alternative; boundary="============_-1118250761==_ma============" --============_-1118250761==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Tero, Sorry for the confusion. The intent in 2401bis was to simplify, and thus to remove the special case of creating two SAs based on one SPD entry. We missed the text in 4.4.1 that still accommodated the AH+ESP case. We will remove it. This also avoids the confusion of whether both SAs are tunnel or transport mode when we had one SPD entry that called for negotiating a pair of SAs, but only one indication of modality, as you noted. Steve --============_-1118250761==_ma============ Content-Type: text/html; charset="us-ascii" RE: [Ipsec] Is AH + ESP required or needed in IKEv2
Tero,

Sorry for the confusion. The intent in 2401bis was to simplify, and thus to remove the special case of creating two SAs based on one SPD entry.  We missed the text in 4.4.1 that still accommodated the AH+ESP case.  We will remove it. This also avoids the confusion of whether both SAs are tunnel or transport mode when we had one SPD entry that called for negotiating a pair of SAs, but only one indication of modality, as you noted.

Steve

--============_-1118250761==_ma============-- --===============1457370192== 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 --===============1457370192==-- From ipsec-bounces@ietf.org Mon Aug 30 17:36:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05372 for ; Mon, 30 Aug 2004 17:36:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1tWK-0003cR-Ny; Mon, 30 Aug 2004 17:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1tLl-0005C7-AR for ipsec@megatron.ietf.org; Mon, 30 Aug 2004 17:06:01 -0400 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 RAA01531 for ; Mon, 30 Aug 2004 17:05:58 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C1tNb-0007h5-Lc for ipsec@ietf.org; Mon, 30 Aug 2004 17:07:56 -0400 Received: (qmail 14703 invoked by uid 0); 30 Aug 2004 21:05:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.169.160) by woodstock.binhost.com with SMTP; 30 Aug 2004 21:05:59 -0000 Message-Id: <6.1.1.1.2.20040830111103.02d8b0a0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 30 Aug 2004 15:21:45 -0400 To: Tero Kivinen , ipsec@ietf.org From: Russ Housley Subject: Re: [Ipsec] Some (hopefully final) comments to the draft-ietf-ipsec-ikev2-15.txt In-Reply-To: <16684.22799.893534.282240@fireball.kivinen.iki.fi> References: <16684.22799.893534.282240@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: angelos@cs.columbia.edu, byfraser@cisco.com, charliek@microsoft.com, tytso@mit.edu, smb@research.att.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 Tero: The IKEv2 document is on the IESG Telechat agenda for this coming Thursday. I put it there because at least one of the ADs has not told us whether the update resolved their DISCUSS comments. I am forcing the issue. If another version is needed to resolve this comment, then the changes can be made at the same time. Otherwise, I think a RFC Editor not is appropriate, Russ Tero Kivinen wrote: >I just finished reading the draft-ietf-ipsec-ikev2-15.txt completely >again. I found some small points, which probably can either be left as >they are or fixed during the authors 48 hours notice... > >Perhaps the area directors can confirm whether we can fix those in >last edit phase, if not, then I think we can just leave the changes >out (the only real issue is the issue number 3 below, as it will >affect interoperability). > >---------------------------------------------------------------------- > >1) Section 3.6 Certificate Payload refers X.509 certificates and CLRs > as a BER encoded x.509 certificate / CRL. I think it should use DER > instead of BER. Of course DER is a subset of BER, so all DER > encoded objects are also BER encoded, but not other way around, and > the certificates etc must always DER encoding, as it must be same > regardless who encoded it. > > I have seen some LDAP servers who took DER encoded certificate, and > re-encoded it using BER when sending it out, and that of course > caused the signatures to fail etc. > >so change > > X.509 Certificate - Signature (4) contains a BER encoded X.509 > certificate whose public key is used to validate the sender's AUTH > payload. > > Certificate Revocation List (7) contains a BER encoded X.509 > certificate revocation list. > >to > > X.509 Certificate - Signature (4) contains a DER encoded X.509 > certificate whose public key is used to validate the sender's AUTH > payload. > > Certificate Revocation List (7) contains a DER encoded X.509 > certificate revocation list. > > >and > > Hash and URL encodings (12-13) allow IKE messages to remain short > by replacing long data structures with a 20 octet SHA-1 hash of > the replaced value followed by a variable length URL that resolves > to the BER encoded data structure itself. ... > >to > > Hash and URL encodings (12-13) allow IKE messages to remain short > by replacing long data structures with a 20 octet SHA-1 hash of > the replaced value followed by a variable length URL that resolves > to the DER encoded data structure itself. ... > >---------------------------------------------------------------------- > >2) Section 3.7 Certificate Request Payload refers still in one place > to CA name instead of the hash of the CA public key. > >so change > > means. Thus the processing of a CERTREQ CA name should be seen as a > suggestion for a certificate to select, not a mandated one. If no > certificates exist then the CERTREQ is ignored. This is not an error > >to > > means. Thus the processing of a CERTREQ should be seen as a > suggestion for a certificate to select, not a mandated one. If no > certificates exist then the CERTREQ is ignored. This is not an error > >There is also extra " at the end of that paragraph, which can be >removed at the same time... > >---------------------------------------------------------------------- > >3) Section 3.15.1 Configuration Attributes has a table listing which > of the attributes are multivalued and which are not. The > INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET are listed in the table > as NO (i.e. not multivalued), but the describing text later says > "The responder MAY respond with zero or more sub-network > attributes.", which indicates that they should be multivalued. > > As it do make sense to send multiple subnets, I think the text is > correct and the table is incorrect. > >so change: > > INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets > SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 > INTERNAL_IP6_SUBNET 15 NO 17 octets > >to > > INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets > SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 > INTERNAL_IP6_SUBNET 15 YES 17 octets > >---------------------------------------------------------------------- > >4) RFC2401bis reference should have the draft name, as it would make > rfc-editors life easier when finding the correct reference, and > fixing it to match the rfc number. > >so change: > > [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture > for the Internet Protocol", un-issued Internet > Draft, work in progress. > >to > > [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture > for the Internet Protocol", draft-ietf-ipsec- > rfc2401bis-02.txt, April 2004, work in progress. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 14:25:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12397 for ; Tue, 31 Aug 2004 14:25:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2DFb-000333-Mz; Tue, 31 Aug 2004 14:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2DCN-00027Z-LT for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 14:17:39 -0400 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 OAA11770 for ; Tue, 31 Aug 2004 14:17:38 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2DEO-0002cH-6j for ipsec@ietf.org; Tue, 31 Aug 2004 14:19:45 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VIDRd25849 for ; Tue, 31 Aug 2004 14:13:27 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VIEgDQ000061 for ; Tue, 31 Aug 2004 14:14:42 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net(66.80.10.146) by nutshell.tislabs.com via csmap (V6.0) id srcAAAT3aWga; Tue, 31 Aug 04 14:14:39 -0400 Received: from [10.1.5.96] ([10.1.5.96]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id i7VIHXlx030717; Tue, 31 Aug 2004 11:17:34 -0700 From: suren To: pki4ipsec@honor.icsalabs.com Content-Type: text/plain Organization: Intoto, Inc. Message-Id: <1093975729.2123.47.camel@suren> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 31 Aug 2004 11:08:49 -0700 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com Subject: [Ipsec] HASH and URL X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: suren@intotoinc.com 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, As I understand, the IKE node can send Hash of public key of its certificate and URL (including port number) from which the peer can retrieve its certificate. I guess, it is to ensure that there is no fragmentation on IKE packets as some routers might not honor fragmentation. I see that there would be firewall related issues in this. Since, the IKE needs to make a new connection (HTTP connection) to the URI given in Cert payload, any firewalls in between should have a policy (ACL) to allow this HTTP connection. This could be a deployment problem. The administrator of firewall need to create a ACL to allow all connections outbound. This is one of the problem being faced by administrators on CRLDP (CRL Distribution point) too. At least in this case, the distribution points are smaller and in most cases deterministic and the administrator of firewalls can create appropriate policies statically. What do you think of this following proposal. - IKE Peer which receives Certificate payload always sends its IP address and port as part of URL. (Assumption here is that, all services typically are allowed between IPSec Peers). - When the IKE node receives HTTP request, it could send HTTP Redirect to new URL, which could be outside its node. - IKE Peer is expected to use same source IP address and Port (May be using REUSE address option in sockets) to connect to new HTTP Server and Port. - Since, most of firewalls support 'address binding' feature, it should work. Does this make sense? Comments? Thanks Suren www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 14:47:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15203 for ; Tue, 31 Aug 2004 14:47:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Dcj-0001Fz-K3; Tue, 31 Aug 2004 14:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Db5-0000zG-Lm for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 14:43:11 -0400 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 OAA14782 for ; Tue, 31 Aug 2004 14:43:10 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Dd7-0003I2-JP for ipsec@ietf.org; Tue, 31 Aug 2004 14:45:17 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VIcxd28578 for ; Tue, 31 Aug 2004 14:39:00 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VIeAFS003529 for ; Tue, 31 Aug 2004 14:40:10 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAefaW3g; Tue, 31 Aug 04 14:40:08 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i7VIgsc01196 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 31 Aug 2004 14:42:55 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i7VIn3819437 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 31 Aug 2004 14:49:09 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VIfV2e014807; Tue, 31 Aug 2004 14:41:31 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VIfSl9014804; Tue, 31 Aug 2004 14:41:28 -0400 To: pki4ipsec@honor.icsalabs.com, ipsec@lists.tislabs.com In-Reply-To: Message from suren of "31 Aug 2004 11:08:49 PDT." <1093975729.2123.47.camel@suren> References: <1093975729.2123.47.camel@suren> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Aug 2004 14:41:28 -0400 Message-ID: <14803.1093977688@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 2.3 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Ipsec] big IKE 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 -----BEGIN PGP SIGNED MESSAGE----- I wonder if one solution to the problem of large IKE packets (that require fragmentation) wouldn't be to define a fragmentation header in IKE. I.e. an IKEv2 payload which contains a sequence number, into which fragments of another IKEv2 payload could be placed. The sender would be responsible for making sure that all fragments get sent (since each would be ACK'ed in some way by the receiver). The only problem that I see is that the original payload will need some kind of response, and so I wonder whether or not to include the IKE header as well as the payload. Original packet: IP UDP IKE-header SK{CERT, AUTH, stuff} new packets: IP UDP IKE-header SK{Frag#1{CERT....}} <- IP UDP IKE-header SK{FragAck#1}} IP UDP IKE-header SK{Frag#2{AUTH....}} <- IP UDP IKE-header SK{FragAck#2}} IP UDP IKE-header SK{Frag#3{stuff...}} <- IP UDP IKE-header SK{FragAck#3, AUTH, stuff}} or perhaps: IP UDP IKE-header SK{Frag#1{IKE-header', CERT....}} <- IP UDP IKE-header SK{FragAck#1}} IP UDP IKE-header SK{Frag#2{AUTH....}} <- IP UDP IKE-header SK{FragAck#2}} IP UDP IKE-header SK{Frag#3{stuff...}} <- IP UDP IKE-header SK{FragAck#3} <- IP UDP IKE-header' SK{AUTH, stuff} - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |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 iQCVAwUBQTTGU4qHRg3pndX9AQEhlQQA1MA58nYdEmjUSdW+bq4tFuht9llO8e7I zR2ObFzsKzoADOZbxp1YtKO1DEhuNz8LFb9yYi+gHbJ1x6l+p8K5JylzsvrxwrU7 xh4mKYno2QGMKw8bfgaZsFTcDpdPkesqOJwVy3ugkxUNvVdAuRgy6M4DvoXaXvk0 PqpDph0rRUE= =+9Qv -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 15:07:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16935 for ; Tue, 31 Aug 2004 15:07:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Dt8-0006tC-Sr; Tue, 31 Aug 2004 15:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2DsK-000636-KM for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 15:01:02 -0400 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 PAA16165 for ; Tue, 31 Aug 2004 15:00:57 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2DuG-0003ht-02 for ipsec@ietf.org; Tue, 31 Aug 2004 15:03:04 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VIucd00359 for ; Tue, 31 Aug 2004 14:56:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VIvoWC006135 for ; Tue, 31 Aug 2004 14:57:50 -0400 (EDT) Received: from sadr.equallogic.com(66.155.203.134) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJOai_l; Tue, 31 Aug 04 14:57:47 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i7VJ0bFn015118 for ; Tue, 31 Aug 2004 15:00:37 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i7VJ0bsw015113; Tue, 31 Aug 2004 15:00:37 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 15:00:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16692.51923.636395.47486@gargle.gargle.HOWL> Date: Tue, 31 Aug 2004 15:00:35 -0400 From: Paul Koning To: mcr@sandelman.ottawa.on.ca Subject: Re: [Ipsec] big IKE packets References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 31 Aug 2004 19:00:37.0158 (UTC) FILETIME=[CD0CD460:01C48F8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.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 >>>>> "Michael" == Michael Richardson writes: Michael> -----BEGIN PGP SIGNED MESSAGE----- I wonder if one solution Michael> to the problem of large IKE packets (that require Michael> fragmentation) wouldn't be to define a fragmentation header Michael> in IKE. Michael> I.e. an IKEv2 payload which contains a sequence number, into Michael> which fragments of another IKEv2 payload could be placed. Michael> The sender would be responsible for making sure that all Michael> fragments get sent (since each would be ACK'ed in some way Michael> by the receiver). If we're not satisfied with how IP does fragmentation, wouldn't it be more reasonable to use TCP -- which handles large packets the right way? I dislike inventing new protocols to address previously solved problems. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 15:26:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19349 for ; Tue, 31 Aug 2004 15:26:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2E7y-00089X-KH; Tue, 31 Aug 2004 15:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2E3t-0006AK-F9 for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 15:12:57 -0400 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 PAA17808 for ; Tue, 31 Aug 2004 15:12:56 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2E5u-00041P-Jv for ipsec@ietf.org; Tue, 31 Aug 2004 15:15:03 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VJ8kd01375 for ; Tue, 31 Aug 2004 15:08:46 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VJA0sp007742 for ; Tue, 31 Aug 2004 15:10:00 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAACNa4gp; Tue, 31 Aug 04 15:09:56 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i7VJChi01525 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 31 Aug 2004 15:12:49 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i7VJJ8820434 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 31 Aug 2004 15:19:14 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VJBa50016040; Tue, 31 Aug 2004 15:11:36 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VJBXqd016036; Tue, 31 Aug 2004 15:11:36 -0400 To: Paul Koning Subject: Re: [Ipsec] big IKE packets In-Reply-To: Message from Paul Koning of "Tue, 31 Aug 2004 15:00:35 EDT." <16692.51923.636395.47486@gargle.gargle.HOWL> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Aug 2004 15:11:33 -0400 Message-ID: <16035.1093979493@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 2.3 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Koning writes: Michael> I.e. an IKEv2 payload which contains a sequence number, Michael> into which fragments of another IKEv2 payload could be Michael> placed. Michael> The sender would be responsible for making sure that all Michael> fragments get sent (since each would be ACK'ed in some way Michael> by the receiver). Paul> If we're not satisfied with how IP does fragmentation, Paul> wouldn't it be more reasonable to use TCP -- which handles Paul> large packets the right way? There are two problems with how IP does fragmentation, and they aren't about IP itself. 1) fragments are hard for firewalls to filter, so they get lost. 2) fragment reassembly under fragment DOS is often not very fruitful. (And then there is the IPv6 situation. IPv6 just tells you to do go the right PMTU yourself, or fragment yourself. This method can get us the PMTU) Paul> I dislike inventing new protocols to address previously solved Paul> problems. We could have an option to run over TCP. But, consider if one is doing IPsec in the first place to protect TCP management sessions. Ooops. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |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 iQCVAwUBQTTNZIqHRg3pndX9AQFzJgP/WtGADQ+ls9fUAz5ynZQymKRMwOEkDcu1 3hj3oxdTH/v6vPgR6w4pCZ9AUItqcElgGFD0TCmgxfticJdNZ61jJrr3JDxNf9Fm EB8xzHl/sFwlCXD3lu4a6XNzws8cMSXtglHrt8gwcMlh6MQDtyzPjEVZTHYUzJtM xqV5GaqF3Gk= =6u0k -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 16:37:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29995 for ; Tue, 31 Aug 2004 16:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2F8A-000116-L8; Tue, 31 Aug 2004 16:21:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2EV6-0002r0-Cq for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 15:41:04 -0400 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 PAA20747 for ; Tue, 31 Aug 2004 15:41:02 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2EX7-0004ie-JY for ipsec@ietf.org; Tue, 31 Aug 2004 15:43:11 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VJaqd04322 for ; Tue, 31 Aug 2004 15:36:52 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VJc6QK012226 for ; Tue, 31 Aug 2004 15:38:06 -0400 (EDT) Received: from sadr.equallogic.com(66.155.203.134) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYnaq1x; Tue, 31 Aug 04 15:38:02 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i7VJerFn017944 for ; Tue, 31 Aug 2004 15:40:54 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i7VJeqsw017939; Tue, 31 Aug 2004 15:40:53 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 31 Aug 2004 15:40:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16692.54339.116599.315927@gargle.gargle.HOWL> Date: Tue, 31 Aug 2004 15:40:51 -0400 From: Paul Koning To: mcr@sandelman.ottawa.on.ca Subject: Re: [Ipsec] big IKE packets References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 31 Aug 2004 19:40:52.0423 (UTC) FILETIME=[6CA90570:01C48F92] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.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 >>>>> "Michael" == Michael Richardson writes: Paul> If we're not satisfied with how IP does fragmentation, wouldn't Paul> it be more reasonable to use TCP -- which handles large packets Paul> the right way? Michael> There are two problems with how IP does fragmentation, and Michael> they aren't about IP itself. 1) fragments are hard for Michael> firewalls to filter, so they get lost. 2) fragment Michael> reassembly under fragment DOS is often not very fruitful. Michael> (And then there is the IPv6 situation. IPv6 just tells you Michael> to do go the right PMTU yourself, or fragment yourself. This Michael> method can get us the PMTU) True. Paul> I dislike inventing new protocols to address previously solved Paul> problems. Michael> We could have an option to run over TCP. But, consider if Michael> one is doing IPsec in the first place to protect TCP Michael> management sessions. Ooops. So? That's no more an issue than it is for UDP. A TCP IKE session would not go through IPsec, just like port 500 UDPgrams don't use IPsec. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 16:46:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00895 for ; Tue, 31 Aug 2004 16:46:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2FEo-0005Mx-DF; Tue, 31 Aug 2004 16:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2EvG-0001Xz-IT for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 16:08:06 -0400 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 QAA24977 for ; Tue, 31 Aug 2004 16:08:02 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2ExE-0006Ac-NG for ipsec@ietf.org; Tue, 31 Aug 2004 16:10:11 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VK3od06837 for ; Tue, 31 Aug 2004 16:03:50 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VK54jP016084 for ; Tue, 31 Aug 2004 16:05:04 -0400 (EDT) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAAc2aOxF; Tue, 31 Aug 04 16:04:58 -0400 Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7VK7p35009260 for ; Tue, 31 Aug 2004 13:07:52 -0700 (PDT) Received: from localhost (punchin-danmcd.SFBay.Sun.COM [192.9.61.10]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i7VK7ocC003124 for ; Tue, 31 Aug 2004 13:07:51 -0700 (PDT) Received: from nowhere.sfbay.sun.com (localhost [127.0.0.1]) by localhost (8.13.0+Sun/8.13.0) with ESMTP id i7VK6Sqo100696; Tue, 31 Aug 2004 16:06:29 -0400 (EDT) Received: (from danmcd@localhost) by nowhere.sfbay.sun.com (8.13.0+Sun/8.13.0/Submit) id i7VK6Rq7100695; Tue, 31 Aug 2004 16:06:27 -0400 (EDT) Date: Tue, 31 Aug 2004 16:06:27 -0400 From: Dan McDonald To: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.com Subject: Re: [Ipsec] big IKE packets Message-ID: <20040831200627.GJ100496@nowhere.sfbay.sun.com> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16035.1093979493@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 > There are two problems with how IP does fragmentation, and they aren't > about IP itself. > 1) fragments are hard for firewalls to filter, so they get lost. Can't modern firewalls tag the initial segment's ID, and let matching IDs through? I know there's packet reordering and implementations that send the last fragment first, but the former is relatively rare, and the latter can be fixed. > (And then there is the IPv6 situation. IPv6 just tells you to do go > the right PMTU yourself, or fragment yourself. This method can get us > the PMTU) And IPv4 can be configured to act just like IPv6 in this regard. Our IP, for example, sets the DF bit by default on outbound packets. > Paul> I dislike inventing new protocols to address previously solved > Paul> problems. I agree with Paul 100%. Let's not reinvent the wheel more than we have to in IKEv2. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 16:53:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01759 for ; Tue, 31 Aug 2004 16:53:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2FUk-0004Jl-8C; Tue, 31 Aug 2004 16:44:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2FBZ-00034B-DD for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 16:24:57 -0400 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 QAA27981 for ; Tue, 31 Aug 2004 16:24:55 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2FDb-00078G-3P for ipsec@ietf.org; Tue, 31 Aug 2004 16:27:04 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VKKjd08850 for ; Tue, 31 Aug 2004 16:20:45 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VKLxJm018681 for ; Tue, 31 Aug 2004 16:22:00 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAajayDK; Tue, 31 Aug 04 16:21:55 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i7VKOke01960 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 31 Aug 2004 16:24:47 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i7VKUw822380 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 31 Aug 2004 16:31:04 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VKNQtT018121; Tue, 31 Aug 2004 16:23:26 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VKNP2H018118; Tue, 31 Aug 2004 16:23:25 -0400 To: Paul Koning Subject: Re: [Ipsec] big IKE packets In-Reply-To: Message from Paul Koning of "Tue, 31 Aug 2004 15:40:51 EDT." <16692.54339.116599.315927@gargle.gargle.HOWL> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Aug 2004 16:23:25 -0400 Message-ID: <18117.1093983805@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 2.3 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Koning writes: Michael> We could have an option to run over TCP. But, consider if Michael> one is doing IPsec in the first place to protect TCP Michael> management sessions. Ooops. Paul> So? That's no more an issue than it is for UDP. A TCP IKE Paul> session would not go through IPsec, just like port 500 Paul> UDPgrams don't use IPsec. But, they would be vulnerable to the TCP RST attacks that we might in fact trying to defend against in the first place. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |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 iQCVAwUBQTTePIqHRg3pndX9AQGvugP+LkHcpP9AeXKpSk1IxZn6ltWYWWhP1vHa GtfQ0hS6xKcedZxlfNpKXQBc1CT96GNLOjAALzBrBffOpOi8Ukz98AVno3nI6D18 Gg7wZeIBSxIJnhJ6sg3HeWKpIc7iZrRTFWsV5KSg9o1qySYIbWxBAyMaTnY0klGZ KslXiv69Ztk= =ue5L -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 17:03:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02488 for ; Tue, 31 Aug 2004 17:03:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2FbQ-0006lD-U9; Tue, 31 Aug 2004 16:51:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2FP9-0002ZO-KY for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 16:38:59 -0400 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 QAA00145 for ; Tue, 31 Aug 2004 16:38:57 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2FRC-0007Yg-Ni for ipsec@ietf.org; Tue, 31 Aug 2004 16:41:07 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VKYmd10230 for ; Tue, 31 Aug 2004 16:34:48 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VKa3Dq020614 for ; Tue, 31 Aug 2004 16:36:03 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7ia4pO; Tue, 31 Aug 04 16:35:59 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i7VKcme02048 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 31 Aug 2004 16:38:51 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i7VKjh822699 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 31 Aug 2004 16:45:49 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VKcBXZ018434; Tue, 31 Aug 2004 16:38:11 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VKcAIG018431; Tue, 31 Aug 2004 16:38:11 -0400 To: Dan McDonald Subject: Re: [Pki4ipsec] Re: [Ipsec] big IKE packets In-Reply-To: Message from Dan McDonald of "Tue, 31 Aug 2004 16:06:27 EDT." <20040831200627.GJ100496@nowhere.sfbay.sun.com> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <20040831200627.GJ100496@nowhere.sfbay.sun.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Aug 2004 16:38:10 -0400 Message-ID: <18430.1093984690@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 2.3 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan McDonald writes: Dan> Can't modern firewalls tag the initial segment's ID, and let Dan> matching IDs through? I know there's packet reordering and Dan> implementations that send the last fragment first, but the Dan> former is relatively rare, and the latter can be fixed. Yes, modern firewalls do all of this. But, consumer grade DSL sharing devices, and multiple "cheap" DSLAM boxes that provide for "virus protection" do not do this. My experience is that neither side of the IPsec connection was in control of these boxes, often unaware of them, and worse -- the ISPs themselves were often ignorant of them. IKEv1 PSK will work fine, or RSA without CERTREQ/CERT, but not with the CERT in place. Dan> And IPv4 can be configured to act just like IPv6 in this Dan> regard. Our IP, for example, sets the DF bit by default on Dan> outbound packets. Paul> I dislike inventing new protocols to address previously solved Paul> problems. Dan> I agree with Paul 100%. Let's not reinvent the wheel more than Dan> we have to in IKEv2. I agree. I'd rather use TCP. I don't think it is practical to do that. (remember, that I'd prefer never to send the certificates in-band at all...) - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |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 iQCVAwUBQTThsYqHRg3pndX9AQFI3gP+KHxGI53iwsgEbLRPKUAo5JjPywVX/Apv hKGRY72m6A6AKLNr+aGLz1MYwruYPHRVKd9sbEB5uT0xC3RkR9vGyUOvT1DvF7U3 pQ2gMf/zQ1Pnp3zq6LgEVBd/9eYloUc87CkVszvgvPVLGV1lEeFv7Tb1K4YqXOoz dujVlPZjGSA= =dk/J -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 17:22:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03884 for ; Tue, 31 Aug 2004 17:22:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2FyH-0003Zl-FA; Tue, 31 Aug 2004 17:15:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Fgg-00086q-Sd for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 16:57:06 -0400 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 QAA02100 for ; Tue, 31 Aug 2004 16:57:05 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Fii-0008Cl-Tj for ipsec@ietf.org; Tue, 31 Aug 2004 16:59:14 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VKqtd11805 for ; Tue, 31 Aug 2004 16:52:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VKs8GR022862 for ; Tue, 31 Aug 2004 16:54:08 -0400 (EDT) Received: from mail-ash.bigfish.com(206.16.192.253) by nutshell.tislabs.com via csmap (V6.0) id srcAAAY5aGOS; Tue, 31 Aug 04 16:54:04 -0400 Received: from mail86-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail86-ash-R.bigfish.com (Postfix) with ESMTP id 534633508D8; Tue, 31 Aug 2004 20:57:02 +0000 (UCT) X-BigFish: V Received: by mail86-ash (MessageSwitch) id 1093985822316419_19939; Tue, 31 Aug 2004 20:57:02 +0000 (UCT) Received: from sjcxch03.tbu.com (unknown [208.10.194.50]) by mail86-ash.bigfish.com (Postfix) with ESMTP id 121D6300F7B; Tue, 31 Aug 2004 20:57:02 +0000 (UCT) Received: from FRAXCH01.tbu.com ([172.18.2.251]) by sjcxch03.tbu.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 13:56:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Ipsec] big IKE packets MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Aug 2004 16:56:51 -0400 Message-ID: Thread-Topic: [Ipsec] big IKE packets Thread-Index: AcSPm4ofUd3tkgMRSmm4K54Z1cEqBgAARijA From: "Bob Doud" To: "Dan McDonald" , , X-OriginalArrivalTime: 31 Aug 2004 20:56:56.0766 (UTC) FILETIME=[0D387DE0:01C48F9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 >=20 > Can't modern firewalls tag the initial segment's ID, and let=20 > matching IDs > through? I know there's packet reordering and=20 > implementations that send the > last fragment first, but the former is relatively rare, and=20 > the latter can be fixed. Keep in mind that Linux implemenations send out the last fragment first, so you're going to see a lot of that. We're not going to hold our breath waiting for that to be changed! Bob _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 19:36:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12461 for ; Tue, 31 Aug 2004 19:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2I4a-0003Pu-Rw; Tue, 31 Aug 2004 19:29:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Hyn-0002Qt-Uk for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 19:23:58 -0400 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 TAA11547 for ; Tue, 31 Aug 2004 19:23:54 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2I0q-0002Kp-Cu for ipsec@ietf.org; Tue, 31 Aug 2004 19:26:06 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VNJhd20489 for ; Tue, 31 Aug 2004 19:19:43 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VNKv5q009201 for ; Tue, 31 Aug 2004 19:20:57 -0400 (EDT) Received: from above.proper.com(208.184.76.39) by nutshell.tislabs.com via csmap (V6.0) id srcAAAH9ay9r; Tue, 31 Aug 04 19:20:54 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VNNREF013593; Tue, 31 Aug 2004 16:23:36 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <18117.1093983805@marajade.sandelman.ottawa.on.ca> References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> Date: Tue, 31 Aug 2004 16:23:27 -0700 To: Michael Richardson From: Paul Hoffman / VPNC Subject: Re: [Ipsec] big IKE packets Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.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 It would be a lot easier for those of us who think "let's not re-invent TCP in IKEv2" to know what you are talking about if we had an Internet Draft will your full proposal for the fragment handling. Without that, we'll just keep saying "it's too hard, and it's not important enough" and you'll keep saying "it really isn't, and it is important". --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 31 19:41:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12954 for ; Tue, 31 Aug 2004 19:41:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ICM-0005Ok-HK; Tue, 31 Aug 2004 19:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2I5W-0003fE-RW for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 19:30:54 -0400 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 TAA11965 for ; Tue, 31 Aug 2004 19:30:52 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2I7Z-0002Qi-F5 for ipsec@ietf.org; Tue, 31 Aug 2004 19:33:03 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7VNQgd20825 for ; Tue, 31 Aug 2004 19:26:42 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7VNRuWE010280 for ; Tue, 31 Aug 2004 19:27:56 -0400 (EDT) Received: from unknown(209.167.151.103) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5AaWeu; Tue, 31 Aug 04 19:27:54 -0400 Date: Tue, 31 Aug 2004 19:30:47 -0500 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xhnwtqtyyttcokbraury" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] foto 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 ----------xhnwtqtyyttcokbraury Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit foto


----------xhnwtqtyyttcokbraury Content-Type: text/html; name="fotos.zip.htm" Content-Disposition: attachment; filename="fotos.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: fotos.zip
Virus name: JS/IllWill

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------xhnwtqtyyttcokbraury 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 ----------xhnwtqtyyttcokbraury-- From ipsec-bounces@ietf.org Tue Aug 31 20:22:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16927 for ; Tue, 31 Aug 2004 20:22:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2IlX-0007Ly-AG; Tue, 31 Aug 2004 20:14:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Ic3-0003rp-FC for ipsec@megatron.ietf.org; Tue, 31 Aug 2004 20:04:31 -0400 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 UAA15023 for ; Tue, 31 Aug 2004 20:04:30 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Ie5-0003Jg-CD for ipsec@ietf.org; Tue, 31 Aug 2004 20:06:40 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8100Hd22661 for ; Tue, 31 Aug 2004 20:00:17 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i8101WU6013687 for ; Tue, 31 Aug 2004 20:01:32 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVUaWRA; Tue, 31 Aug 04 20:01:26 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i8102lg03320 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 31 Aug 2004 20:04:03 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i8108w827249 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 31 Aug 2004 20:09:04 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VNxtnk027213; Tue, 31 Aug 2004 19:59:55 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i7VNxqK2027209; Tue, 31 Aug 2004 19:59:53 -0400 To: Paul Hoffman / VPNC Subject: Re: [Ipsec] big IKE packets In-Reply-To: Message from Paul Hoffman / VPNC of "Tue, 31 Aug 2004 16:23:27 PDT." References: <1093975729.2123.47.camel@suren> <14803.1093977688@marajade.sandelman.ottawa.on.ca> <16692.51923.636395.47486@gargle.gargle.HOWL> <16035.1093979493@marajade.sandelman.ottawa.on.ca> <16692.54339.116599.315927@gargle.gargle.HOWL> <18117.1093983805@marajade.sandelman.ottawa.on.ca> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 31 Aug 2004 19:59:52 -0400 Message-ID: <27208.1093996792@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 2.3 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipsec@lists.tislabs.com, pki4ipsec@honor.icsalabs.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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> It would be a lot easier for those of us who think "let's not VPNC> re-invent TCP in IKEv2" to know what you are talking about if VPNC> we had an Internet Draft will your full proposal for the VPNC> fragment handling. Without that, we'll just keep saying "it's VPNC> too hard, and it's not important enough" and you'll keep VPNC> saying "it really isn't, and it is important". Remember, that I'm the guy who thinks that one of the reasons that certificates shouldn't be exchanged in-band is because of problems like this :-) I do, however, hate PSK, and want it to go away, so if solving this problem makes progress, then I'm willing to help. I twigged on this after reading parts of the last month of the pki4ipsec list, and started to think about it in the shower or something. I would be happy to write a document --- but others need to say, "yes, solving the cert too-big-for-MTU is important". - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |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 iQCVAwUBQTUQ9oqHRg3pndX9AQF4DwP/WsD+KsE3O+e+HXZ/kyQL6k1kBAHXfik0 iI5jK3/su22KOifPqcTxPjDLp/zYAyd299SNbL8jmKiRNE6jSlC0+Kohjt5DcqhV gaGNHbihklX/7ve5YIhpyMo5h8BkN5lSFeEGY9JFxteCac3xlvtGz2/x8uPAZrJb tY6AC9xCxLA= =mJaA -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec