From mailman-admin@ietf.org Sat May 1 09:43:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14543 for ; Sat, 1 May 2004 09:43:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJu9f-00024w-Hk for ipsec-archive@lists.ietf.org; Sat, 01 May 2004 09:03:43 -0400 Date: Sat, 01 May 2004 09:03:43 -0400 Message-ID: <20040501130343.27207.18076.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ipsec-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, ipsec-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 All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.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-admin@ietf.org Mon May 3 12:33:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11537 for ; Mon, 3 May 2004 12:33:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgEd-0004cU-HN; Mon, 03 May 2004 12:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKg4e-0001Ft-Ra for ipsec@optimus.ietf.org; Mon, 03 May 2004 12:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10414 for ; Mon, 3 May 2004 12:13:41 -0400 (EDT) From: Dave_Perks@mitel.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKg4d-00042J-Be for ipsec@ietf.org; Mon, 03 May 2004 12:13:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKg3k-0003yk-00 for ipsec@ietf.org; Mon, 03 May 2004 12:12:48 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BKg2m-0003ut-00 for ipsec@ietf.org; Mon, 03 May 2004 12:11:49 -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 i43GAkv01884 for ; Mon, 3 May 2004 12:10:46 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i43G5s3s006460 for ; Mon, 3 May 2004 12:05:55 -0400 (EDT) Received: from unknown(68.234.139.43) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZHaOrm; Mon, 3 May 04 12:04:52 -0400 Date: Mon, 03 May 2004 12:05:19 -0500 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tbvglgsxnidyjfylqwcm" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Hello Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------tbvglgsxnidyjfylqwcm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Your file is attached.


----------tbvglgsxnidyjfylqwcm Content-Type: text/html; name="Gift.pif.htm" Content-Disposition: attachment; filename="Gift.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: Gift.pif
Virus name: W32/Bagle.p@MM

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

----------tbvglgsxnidyjfylqwcm-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 3 12:52:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13239 for ; Mon, 3 May 2004 12:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgZH-0001IX-Lu for ipsec-archive@odin.ietf.org; Mon, 03 May 2004 12:45:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43GjNKO004989 for ipsec-archive@odin.ietf.org; Mon, 3 May 2004 12:45:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgPC-00072u-V3 for ipsec-web-archive@optimus.ietf.org; Mon, 03 May 2004 12:34:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11669 for ; Mon, 3 May 2004 12:34:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKgPB-0005j0-D6 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 12:34:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgON-0005eR-00 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 12:34:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKgNk-0005YS-00 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 12:33:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgEd-0004cU-HN; Mon, 03 May 2004 12:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKg4e-0001Ft-Ra for ipsec@optimus.ietf.org; Mon, 03 May 2004 12:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10414 for ; Mon, 3 May 2004 12:13:41 -0400 (EDT) From: Dave_Perks@mitel.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKg4d-00042J-Be for ipsec@ietf.org; Mon, 03 May 2004 12:13:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKg3k-0003yk-00 for ipsec@ietf.org; Mon, 03 May 2004 12:12:48 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BKg2m-0003ut-00 for ipsec@ietf.org; Mon, 03 May 2004 12:11:49 -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 i43GAkv01884 for ; Mon, 3 May 2004 12:10:46 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i43G5s3s006460 for ; Mon, 3 May 2004 12:05:55 -0400 (EDT) Received: from unknown(68.234.139.43) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZHaOrm; Mon, 3 May 04 12:04:52 -0400 Date: Mon, 03 May 2004 12:05:19 -0500 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tbvglgsxnidyjfylqwcm" Subject: [Ipsec] Re: Hello Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=2.60 ----------tbvglgsxnidyjfylqwcm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Your file is attached.


----------tbvglgsxnidyjfylqwcm Content-Type: text/html; name="Gift.pif.htm" Content-Disposition: attachment; filename="Gift.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: Gift.pif
Virus name: W32/Bagle.p@MM

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

----------tbvglgsxnidyjfylqwcm-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 3 14:12:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17467 for ; Mon, 3 May 2004 14:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhfe-0002M7-Ri; Mon, 03 May 2004 13:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhWm-0000BT-2U for ipsec@optimus.ietf.org; Mon, 03 May 2004 13:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16254 for ; Mon, 3 May 2004 13:46:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhWj-00061J-Gu for ipsec@ietf.org; Mon, 03 May 2004 13:46:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhVu-0005vW-00 for ipsec@ietf.org; Mon, 03 May 2004 13:45:59 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BKhV6-0005q2-00 for ipsec@ietf.org; Mon, 03 May 2004 13:45:08 -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 i43Hi6v10143 for ; Mon, 3 May 2004 13:44:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i43HgT8w022398 for ; Mon, 3 May 2004 13:42:29 -0400 (EDT) Received: from cs176-66.anderson.ucla.edu(164.67.176.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAe9aayR; Mon, 3 May 04 13:41:13 -0400 Date: Mon, 03 May 2004 10:43:28 -0800 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rgudlfzbhrmkcbtiljhw" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Msg reply Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------rgudlfzbhrmkcbtiljhw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rgudlfzbhrmkcbtiljhw Content-Type: text/html; name="Details.hta.htm" Content-Disposition: attachment; filename="Details.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: Details.hta
Virus name: W32/Bagle.aa@MM!vbs

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

----------rgudlfzbhrmkcbtiljhw-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 3 14:37:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19239 for ; Mon, 3 May 2004 14:37:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKi3u-0007ip-G5 for ipsec-archive@odin.ietf.org; Mon, 03 May 2004 14:21:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43IL6br029683 for ipsec-archive@odin.ietf.org; Mon, 3 May 2004 14:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhwt-0006EQ-DQ for ipsec-web-archive@optimus.ietf.org; Mon, 03 May 2004 14:13:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17593 for ; Mon, 3 May 2004 14:13:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhwq-00011d-Vz for ipsec-web-archive@ietf.org; Mon, 03 May 2004 14:13:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhw1-0000uk-00 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 14:12:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKhvA-0000oQ-00 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 14:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhfe-0002M7-Ri; Mon, 03 May 2004 13:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhWm-0000BT-2U for ipsec@optimus.ietf.org; Mon, 03 May 2004 13:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16254 for ; Mon, 3 May 2004 13:46:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhWj-00061J-Gu for ipsec@ietf.org; Mon, 03 May 2004 13:46:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhVu-0005vW-00 for ipsec@ietf.org; Mon, 03 May 2004 13:45:59 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BKhV6-0005q2-00 for ipsec@ietf.org; Mon, 03 May 2004 13:45:08 -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 i43Hi6v10143 for ; Mon, 3 May 2004 13:44:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i43HgT8w022398 for ; Mon, 3 May 2004 13:42:29 -0400 (EDT) Received: from cs176-66.anderson.ucla.edu(164.67.176.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAe9aayR; Mon, 3 May 04 13:41:13 -0400 Date: Mon, 03 May 2004 10:43:28 -0800 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rgudlfzbhrmkcbtiljhw" Subject: [Ipsec] Re: Msg reply Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------rgudlfzbhrmkcbtiljhw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rgudlfzbhrmkcbtiljhw Content-Type: text/html; name="Details.hta.htm" Content-Disposition: attachment; filename="Details.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: Details.hta
Virus name: W32/Bagle.aa@MM!vbs

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

----------rgudlfzbhrmkcbtiljhw-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 3 18:53:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09830 for ; Mon, 3 May 2004 18:53:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmDG-000520-B7; Mon, 03 May 2004 18:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKm1f-0001yE-TP for ipsec@optimus.ietf.org; Mon, 03 May 2004 18:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09103 for ; Mon, 3 May 2004 18:34:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKm1c-0006fJ-QF for ipsec@ietf.org; Mon, 03 May 2004 18:35:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKm0j-0006Ys-00 for ipsec@ietf.org; Mon, 03 May 2004 18:34:05 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BKm03-0006Mv-00 for ipsec@ietf.org; Mon, 03 May 2004 18:33:23 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.29]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41K9F2; Mon, 3 May 2004 18:32:53 -0400 Message-Id: <5.2.0.9.0.20040503182205.0206b470@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 May 2004 18:32:44 -0400 To: Karen Seo From: Mark Duffy Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org In-Reply-To: References: <5.2.0.9.0.20040426124209.020d5968@email> <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040426124209.020d5968@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , >>But in #2 the icmp error message is being sent on an SA negotiated for >>protocol=icmp, type= and code=. It seems to me to be an >>impropriety for the IPsec implementation to check the enclosed >>packet. This would be checking that goes beyond the negotiated selectors >>-- AFAIK there is no other comparable thing done elsewhere in IPsec. > > Hmmm... ICMP messages can more directly cause problems > than regular data traffic. They could be used to > redirect traffic, change the PMTU, etc. So it seemed > to us that additional checking was warranted. > >> Should an IPsec implementation also check for invalid combinations of >> control bits in a tcp header? Or for packets with src addr == dest >> addr? These are also checks that could protect against attacks but they >> oughtn't IMO to be part of the *IPsec* processing. > > I think I understand what you're saying but verifying that > the packet enclosed in an ICMP message could have legitimately > come from an entity behind the local IPsec implementation seems > appropriate given the risks. I would like to at least leave > this check in as a note with a MAY. What do you think? Do > you want this check removed entirely? I'll go for the "MAY" if that's the best I can get :-) If the authors and wg think the check should be there, so be it. But to me it seems inelegant that an implementation should be called upon to make these somewhat-arbitrary checks beyond the negotiated access control policy. IMO if the SA is negotiated for protocol=icmp, with SA, DA, type, and code selectors, that 5-tuple is what should be enforced and no more. --Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 3 19:00:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10250 for ; Mon, 3 May 2004 19:00:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmNO-0007k8-2z for ipsec-archive@odin.ietf.org; Mon, 03 May 2004 18:57:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43MvUE7029759 for ipsec-archive@odin.ietf.org; Mon, 3 May 2004 18:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmL5-0006wZ-EY for ipsec-web-archive@optimus.ietf.org; Mon, 03 May 2004 18:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09925 for ; Mon, 3 May 2004 18:55:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKmL2-0001K7-B4 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 18:55:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKmK5-0001CC-00 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 18:54:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKmJC-00014G-00 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 18:53:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKmDG-000520-B7; Mon, 03 May 2004 18:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKm1f-0001yE-TP for ipsec@optimus.ietf.org; Mon, 03 May 2004 18:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09103 for ; Mon, 3 May 2004 18:34:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKm1c-0006fJ-QF for ipsec@ietf.org; Mon, 03 May 2004 18:35:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKm0j-0006Ys-00 for ipsec@ietf.org; Mon, 03 May 2004 18:34:05 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BKm03-0006Mv-00 for ipsec@ietf.org; Mon, 03 May 2004 18:33:23 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.29]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41K9F2; Mon, 3 May 2004 18:32:53 -0400 Message-Id: <5.2.0.9.0.20040503182205.0206b470@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 May 2004 18:32:44 -0400 To: Karen Seo From: Mark Duffy Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org In-Reply-To: References: <5.2.0.9.0.20040426124209.020d5968@email> <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040426124209.020d5968@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >>But in #2 the icmp error message is being sent on an SA negotiated for >>protocol=icmp, type= and code=. It seems to me to be an >>impropriety for the IPsec implementation to check the enclosed >>packet. This would be checking that goes beyond the negotiated selectors >>-- AFAIK there is no other comparable thing done elsewhere in IPsec. > > Hmmm... ICMP messages can more directly cause problems > than regular data traffic. They could be used to > redirect traffic, change the PMTU, etc. So it seemed > to us that additional checking was warranted. > >> Should an IPsec implementation also check for invalid combinations of >> control bits in a tcp header? Or for packets with src addr == dest >> addr? These are also checks that could protect against attacks but they >> oughtn't IMO to be part of the *IPsec* processing. > > I think I understand what you're saying but verifying that > the packet enclosed in an ICMP message could have legitimately > come from an entity behind the local IPsec implementation seems > appropriate given the risks. I would like to at least leave > this check in as a note with a MAY. What do you think? Do > you want this check removed entirely? I'll go for the "MAY" if that's the best I can get :-) If the authors and wg think the check should be there, so be it. But to me it seems inelegant that an implementation should be called upon to make these somewhat-arbitrary checks beyond the negotiated access control policy. IMO if the SA is negotiated for protocol=icmp, with SA, DA, type, and code selectors, that 5-tuple is what should be enforced and no more. --Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 3 22:06:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16670 for ; Mon, 3 May 2004 22:06:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKpD4-0002yZ-AG; Mon, 03 May 2004 21:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKpBK-0002ex-GH for ipsec@optimus.ietf.org; Mon, 03 May 2004 21:57:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16406 for ; Mon, 3 May 2004 21:57:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKpBH-0001Ow-HF for ipsec@ietf.org; Mon, 03 May 2004 21:57:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKpAJ-0001HE-00 for ipsec@ietf.org; Mon, 03 May 2004 21:56:12 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BKp9r-00019U-00 for ipsec@ietf.org; Mon, 03 May 2004 21:55:43 -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 i441shv11326 for ; Mon, 3 May 2004 21:54:43 -0400 (EDT) Received: from [10.84.130.39] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i441t57p006388; Mon, 3 May 2004 21:55:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.1.0.14.0.20040421124903.0256cd00@172.16.1.10> References: <1081199470.1273.49.camel@suren> <1081199470.1273.49.camel@suren> <5.1.0.14.0.20040421124903.0256cd00@172.16.1.10> Date: Mon, 3 May 2004 21:54:34 -0400 To: Raghava Rao From: Stephen Kent Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] Re: Outbound SA Bundle processing Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 1:46 PM +0530 4/21/04, Raghava Rao wrote: >Hi, > >Same issue was raised in one of the bakeoff (MAY 1999). >Some vendors supported format 2 and some format 1. >But most of the vendors supported one TUNNEL IP header for both AH >and ESP together. > >In my view security over head can be reduced in format 1 >by avoiding the additional TUNNEL IP header construction in the format 2. > >-raghava I won't dispute what vendors may have implemented, but not everything that vendors ave done has been consistent with the RFCs. It is also obvious that omitting an IP layer reduces overhead. If you look at the new processing model, it allows nesting of SAs through a loopback mechanism, using appropriate entries in the SPD and forwarding tables. This model makes it clear that two headers would be required, because each IPsec protocol would be applied on a separate pass across the Ipsec boundary, and thus the IP header structure needed by tunnel mode would have to be present on each pass. so, if there was any ambiguity in 2401 in this regard, it is removed in 2401bis. steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 3 22:09:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16824 for ; Mon, 3 May 2004 22:09:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKpM0-0005A8-7w for ipsec-archive@odin.ietf.org; Mon, 03 May 2004 22:08:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4428Gnn019844 for ipsec-archive@odin.ietf.org; Mon, 3 May 2004 22:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKpLr-0004yR-Ql for ipsec-web-archive@optimus.ietf.org; Mon, 03 May 2004 22:08:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16724 for ; Mon, 3 May 2004 22:08:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKpLo-0002s5-Q4 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 22:08:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKpKq-0002jf-00 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 22:07:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKpK4-0002bu-00 for ipsec-web-archive@ietf.org; Mon, 03 May 2004 22:06:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKpD4-0002yZ-AG; Mon, 03 May 2004 21:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKpBK-0002ex-GH for ipsec@optimus.ietf.org; Mon, 03 May 2004 21:57:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16406 for ; Mon, 3 May 2004 21:57:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKpBH-0001Ow-HF for ipsec@ietf.org; Mon, 03 May 2004 21:57:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKpAJ-0001HE-00 for ipsec@ietf.org; Mon, 03 May 2004 21:56:12 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BKp9r-00019U-00 for ipsec@ietf.org; Mon, 03 May 2004 21:55:43 -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 i441shv11326 for ; Mon, 3 May 2004 21:54:43 -0400 (EDT) Received: from [10.84.130.39] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i441t57p006388; Mon, 3 May 2004 21:55:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.1.0.14.0.20040421124903.0256cd00@172.16.1.10> References: <1081199470.1273.49.camel@suren> <1081199470.1273.49.camel@suren> <5.1.0.14.0.20040421124903.0256cd00@172.16.1.10> Date: Mon, 3 May 2004 21:54:34 -0400 To: Raghava Rao From: Stephen Kent Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Ipsec] Re: Outbound SA Bundle processing Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 At 1:46 PM +0530 4/21/04, Raghava Rao wrote: >Hi, > >Same issue was raised in one of the bakeoff (MAY 1999). >Some vendors supported format 2 and some format 1. >But most of the vendors supported one TUNNEL IP header for both AH >and ESP together. > >In my view security over head can be reduced in format 1 >by avoiding the additional TUNNEL IP header construction in the format 2. > >-raghava I won't dispute what vendors may have implemented, but not everything that vendors ave done has been consistent with the RFCs. It is also obvious that omitting an IP layer reduces overhead. If you look at the new processing model, it allows nesting of SAs through a loopback mechanism, using appropriate entries in the SPD and forwarding tables. This model makes it clear that two headers would be required, because each IPsec protocol would be applied on a separate pass across the Ipsec boundary, and thus the IP header structure needed by tunnel mode would have to be present on each pass. so, if there was any ambiguity in 2401 in this regard, it is removed in 2401bis. steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 4 13:04:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12929 for ; Tue, 4 May 2004 13:04:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3BH-0002ap-Pe; Tue, 04 May 2004 12:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL36A-0000f1-MA for ipsec@optimus.ietf.org; Tue, 04 May 2004 12:48:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12130 for ; Tue, 4 May 2004 12:48:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL368-0001zy-S1 for ipsec@ietf.org; Tue, 04 May 2004 12:48:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL358-0001vO-00 for ipsec@ietf.org; Tue, 04 May 2004 12:47:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BL34G-0001mF-00 for ipsec@ietf.org; Tue, 04 May 2004 12:46:52 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 May 2004 09:46:35 -0700 Received: from [10.32.244.18] (stealth-10-32-244-18.cisco.com [10.32.244.18]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id i44GkI0R025254; Tue, 4 May 2004 09:46:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <76A5E8AE-9DEA-11D8-8A8D-000A95E07B78@cisco.com> Content-Transfer-Encoding: 7bit Cc: Barbara Fraser , kivinen@iki.fi, ipsec@ietf.org, angelos@cs.columbia.edu, "Theodore Y. Ts'o" From: Barbara Fraser Date: Tue, 4 May 2004 09:45:34 -0700 To: Charlie Kaufman X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Updating IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Charlie, The issue tracker contains the issues raised during the IETF last call. Please go ahead and update the document to address these remaining issues. If you have any questions about any of them, please post to the list. We'd like to have a final version as soon as reasonably possible. thanks a bunch, Barb and Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 4 13:18:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13880 for ; Tue, 4 May 2004 13:18:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3VU-0000iL-F2 for ipsec-archive@odin.ietf.org; Tue, 04 May 2004 13:15:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44HF000002739 for ipsec-archive@odin.ietf.org; Tue, 4 May 2004 13:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3Mj-0005rw-8Q for ipsec-web-archive@optimus.ietf.org; Tue, 04 May 2004 13:05:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12984 for ; Tue, 4 May 2004 13:05:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL3Mh-0003cv-F4 for ipsec-web-archive@ietf.org; Tue, 04 May 2004 13:05:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3Li-0003X6-00 for ipsec-web-archive@ietf.org; Tue, 04 May 2004 13:04:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL3LH-0003RQ-00 for ipsec-web-archive@ietf.org; Tue, 04 May 2004 13:04:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3BH-0002ap-Pe; Tue, 04 May 2004 12:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL36A-0000f1-MA for ipsec@optimus.ietf.org; Tue, 04 May 2004 12:48:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12130 for ; Tue, 4 May 2004 12:48:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL368-0001zy-S1 for ipsec@ietf.org; Tue, 04 May 2004 12:48:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL358-0001vO-00 for ipsec@ietf.org; Tue, 04 May 2004 12:47:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BL34G-0001mF-00 for ipsec@ietf.org; Tue, 04 May 2004 12:46:52 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 May 2004 09:46:35 -0700 Received: from [10.32.244.18] (stealth-10-32-244-18.cisco.com [10.32.244.18]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id i44GkI0R025254; Tue, 4 May 2004 09:46:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <76A5E8AE-9DEA-11D8-8A8D-000A95E07B78@cisco.com> Content-Transfer-Encoding: 7bit Cc: Barbara Fraser , kivinen@iki.fi, ipsec@ietf.org, angelos@cs.columbia.edu, "Theodore Y. Ts'o" From: Barbara Fraser Date: Tue, 4 May 2004 09:45:34 -0700 To: Charlie Kaufman X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Ipsec] Updating IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Charlie, The issue tracker contains the issues raised during the IETF last call. Please go ahead and update the document to address these remaining issues. If you have any questions about any of them, please post to the list. We'd like to have a final version as soon as reasonably possible. thanks a bunch, Barb and Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed May 5 03:24:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26551 for ; Wed, 5 May 2004 03:24:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGcV-0007Xk-Kb; Wed, 05 May 2004 03:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGZw-0006ll-PD for ipsec@optimus.ietf.org; Wed, 05 May 2004 03:12:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25930 for ; Wed, 5 May 2004 03:12:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGZu-0007mb-L1 for ipsec@ietf.org; Wed, 05 May 2004 03:12:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGYz-0007cM-00 for ipsec@ietf.org; Wed, 05 May 2004 03:11:30 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLGYY-0007RT-00 for ipsec@ietf.org; Wed, 05 May 2004 03:11:02 -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 i4579wv28975 for ; Wed, 5 May 2004 03:09:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4575av6010200 for ; Wed, 5 May 2004 03:05:36 -0400 (EDT) Received: from pc32003.hum.au.dk(192.38.32.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhYaaQt; Wed, 5 May 04 03:04:43 -0400 Date: Wed, 05 May 2004 09:07:01 +0100 To: "Ipsec" From: "Stephane" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mvzursoavhtcfsvkfhfl" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Document Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------mvzursoavhtcfsvkfhfl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------mvzursoavhtcfsvkfhfl Content-Type: text/html; name="Half_Live.cpl.htm" Content-Disposition: attachment; filename="Half_Live.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: Half_Live.cpl
Virus name: W32/Bagle.aa@MM

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

----------mvzursoavhtcfsvkfhfl-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Wed May 5 03:31:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27030 for ; Wed, 5 May 2004 03:31:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGp2-0002uQ-O5 for ipsec-archive@odin.ietf.org; Wed, 05 May 2004 03:28:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i457S4vw011182 for ipsec-archive@odin.ietf.org; Wed, 5 May 2004 03:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGmU-00020e-S2 for ipsec-web-archive@optimus.ietf.org; Wed, 05 May 2004 03:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26635 for ; Wed, 5 May 2004 03:25:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGmS-0002hP-Kh for ipsec-web-archive@ietf.org; Wed, 05 May 2004 03:25:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGlX-0002T0-00 for ipsec-web-archive@ietf.org; Wed, 05 May 2004 03:24:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLGkc-0002HK-00 for ipsec-web-archive@ietf.org; Wed, 05 May 2004 03:23:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGcV-0007Xk-Kb; Wed, 05 May 2004 03:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLGZw-0006ll-PD for ipsec@optimus.ietf.org; Wed, 05 May 2004 03:12:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25930 for ; Wed, 5 May 2004 03:12:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLGZu-0007mb-L1 for ipsec@ietf.org; Wed, 05 May 2004 03:12:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLGYz-0007cM-00 for ipsec@ietf.org; Wed, 05 May 2004 03:11:30 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLGYY-0007RT-00 for ipsec@ietf.org; Wed, 05 May 2004 03:11:02 -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 i4579wv28975 for ; Wed, 5 May 2004 03:09:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4575av6010200 for ; Wed, 5 May 2004 03:05:36 -0400 (EDT) Received: from pc32003.hum.au.dk(192.38.32.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhYaaQt; Wed, 5 May 04 03:04:43 -0400 Date: Wed, 05 May 2004 09:07:01 +0100 To: "Ipsec" From: "Stephane" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mvzursoavhtcfsvkfhfl" Subject: [Ipsec] Re: Document Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------mvzursoavhtcfsvkfhfl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------mvzursoavhtcfsvkfhfl Content-Type: text/html; name="Half_Live.cpl.htm" Content-Disposition: attachment; filename="Half_Live.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: Half_Live.cpl
Virus name: W32/Bagle.aa@MM

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

----------mvzursoavhtcfsvkfhfl-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed May 5 10:28:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15918 for ; Wed, 5 May 2004 10:28:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNGj-0002UK-G3; Wed, 05 May 2004 10:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN9s-0007JL-IR for ipsec@optimus.ietf.org; Wed, 05 May 2004 10:14:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14969 for ; Wed, 5 May 2004 10:13:57 -0400 (EDT) From: jesse.walker@intel.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLN9q-0003sb-CZ for ipsec@ietf.org; Wed, 05 May 2004 10:13:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLN8r-0003YI-00 for ipsec@ietf.org; Wed, 05 May 2004 10:12:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLN7X-00031T-00 for ipsec@ietf.org; Wed, 05 May 2004 10:11:35 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLMtb-0003AU-Th for ipsec@ietf.org; Wed, 05 May 2004 09:57: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 i45Du6v22692 for ; Wed, 5 May 2004 09:56:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i45DsEYW019827 for ; Wed, 5 May 2004 09:54:15 -0400 (EDT) Received: from host240-200.pool8175.interbusiness.it(81.75.200.240) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfRayFM; Wed, 5 May 04 09:53:25 -0400 Date: Wed, 05 May 2004 15:54:00 +0100 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rdukvytbmckjcupybmfx" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Incoming Fax Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------rdukvytbmckjcupybmfx Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rdukvytbmckjcupybmfx Content-Type: text/html; name="Information.vbs.htm" Content-Disposition: attachment; filename="Information.vbs.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.vbs
Virus name: W32/Bagle.z@MM!vbs

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

----------rdukvytbmckjcupybmfx-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Wed May 5 10:43:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17039 for ; Wed, 5 May 2004 10:43:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNVM-0007Fw-Og for ipsec-archive@odin.ietf.org; Wed, 05 May 2004 10:36:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45EaCMx027893 for ipsec-archive@odin.ietf.org; Wed, 5 May 2004 10:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNP6-0004xA-FM for ipsec-web-archive@optimus.ietf.org; Wed, 05 May 2004 10:29:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16066 for ; Wed, 5 May 2004 10:29:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNP4-0007h5-6E for ipsec-web-archive@ietf.org; Wed, 05 May 2004 10:29:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNO9-0007RJ-00 for ipsec-web-archive@ietf.org; Wed, 05 May 2004 10:28:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLNN7-0007A6-00 for ipsec-web-archive@ietf.org; Wed, 05 May 2004 10:27:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNGj-0002UK-G3; Wed, 05 May 2004 10:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLN9s-0007JL-IR for ipsec@optimus.ietf.org; Wed, 05 May 2004 10:14:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14969 for ; Wed, 5 May 2004 10:13:57 -0400 (EDT) From: jesse.walker@intel.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLN9q-0003sb-CZ for ipsec@ietf.org; Wed, 05 May 2004 10:13:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLN8r-0003YI-00 for ipsec@ietf.org; Wed, 05 May 2004 10:12:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLN7X-00031T-00 for ipsec@ietf.org; Wed, 05 May 2004 10:11:35 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLMtb-0003AU-Th for ipsec@ietf.org; Wed, 05 May 2004 09:57: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 i45Du6v22692 for ; Wed, 5 May 2004 09:56:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i45DsEYW019827 for ; Wed, 5 May 2004 09:54:15 -0400 (EDT) Received: from host240-200.pool8175.interbusiness.it(81.75.200.240) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfRayFM; Wed, 5 May 04 09:53:25 -0400 Date: Wed, 05 May 2004 15:54:00 +0100 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rdukvytbmckjcupybmfx" Subject: [Ipsec] Re: Incoming Fax Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=2.60 ----------rdukvytbmckjcupybmfx Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rdukvytbmckjcupybmfx Content-Type: text/html; name="Information.vbs.htm" Content-Disposition: attachment; filename="Information.vbs.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.vbs
Virus name: W32/Bagle.z@MM!vbs

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

----------rdukvytbmckjcupybmfx-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 6 03:51:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24878 for ; Thu, 6 May 2004 03:51:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdZA-0006L3-Lk; Thu, 06 May 2004 03:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdOv-0002Vc-30 for ipsec@optimus.ietf.org; Thu, 06 May 2004 03:34:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24228 for ; Thu, 6 May 2004 03:34:35 -0400 (EDT) From: ipsec@lists.tislabs.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLdOs-0007FV-OK for ipsec@ietf.org; Thu, 06 May 2004 03:34:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLdO0-0006tE-00 for ipsec@ietf.org; Thu, 06 May 2004 03:33:41 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLdNV-0006WZ-00 for ipsec@ietf.org; Thu, 06 May 2004 03:33: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 i467W5v22075 for ; Thu, 6 May 2004 03:32:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i467UVx8000738 for ; Thu, 6 May 2004 03:30:32 -0400 (EDT) Message-Id: <200405060730.i467UVx8000738@nutshell.tislabs.com> Received: from user-0c8h7o6.cable.mindspring.com(24.136.159.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAD8aqkb; Thu, 6 May 04 03:29:45 -0400 To: ipsec@lists.tislabs.com Date: Thu, 6 May 2004 03:32:21 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_00007153.0000645A" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MISSING_MIMEOLE, MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Here Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0001_00007153.0000645A Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Please read the attached file. ------=_NextPart_000_0001_00007153.0000645A Content-Type: text/html; name="yours.pif.htm" Content-Disposition: attachment; filename="yours.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: yours.pif
Virus name: W32/Netsky.d@MM

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

------=_NextPart_000_0001_00007153.0000645A-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 6 03:59:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25441 for ; Thu, 6 May 2004 03:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdjy-0002wd-9a for ipsec-archive@odin.ietf.org; Thu, 06 May 2004 03:56:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i467uMLL011315 for ipsec-archive@odin.ietf.org; Thu, 6 May 2004 03:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdgI-0001VI-Ny for ipsec-web-archive@optimus.ietf.org; Thu, 06 May 2004 03:52:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25036 for ; Thu, 6 May 2004 03:52:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLdgG-00061Y-9I for ipsec-web-archive@ietf.org; Thu, 06 May 2004 03:52:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLdfT-0005ct-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 03:51:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLdeQ-0005DD-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 03:50:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdZA-0006L3-Lk; Thu, 06 May 2004 03:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLdOv-0002Vc-30 for ipsec@optimus.ietf.org; Thu, 06 May 2004 03:34:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24228 for ; Thu, 6 May 2004 03:34:35 -0400 (EDT) From: ipsec@lists.tislabs.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLdOs-0007FV-OK for ipsec@ietf.org; Thu, 06 May 2004 03:34:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLdO0-0006tE-00 for ipsec@ietf.org; Thu, 06 May 2004 03:33:41 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLdNV-0006WZ-00 for ipsec@ietf.org; Thu, 06 May 2004 03:33: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 i467W5v22075 for ; Thu, 6 May 2004 03:32:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i467UVx8000738 for ; Thu, 6 May 2004 03:30:32 -0400 (EDT) Message-Id: <200405060730.i467UVx8000738@nutshell.tislabs.com> Received: from user-0c8h7o6.cable.mindspring.com(24.136.159.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAD8aqkb; Thu, 6 May 04 03:29:45 -0400 To: ipsec@lists.tislabs.com Date: Thu, 6 May 2004 03:32:21 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_00007153.0000645A" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Ipsec] Re: Here Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.8 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0001_00007153.0000645A Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Please read the attached file. ------=_NextPart_000_0001_00007153.0000645A Content-Type: text/html; name="yours.pif.htm" Content-Disposition: attachment; filename="yours.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: yours.pif
Virus name: W32/Netsky.d@MM

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

------=_NextPart_000_0001_00007153.0000645A-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 6 06:17:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03086 for ; Thu, 6 May 2004 06:17:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfqI-0006gC-PO; Thu, 06 May 2004 06:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfiE-0002gN-3c for ipsec@optimus.ietf.org; Thu, 06 May 2004 06:02:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02482 for ; Thu, 6 May 2004 06:02:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfiA-0001ae-E2 for ipsec@ietf.org; Thu, 06 May 2004 06:02:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfh5-0001CA-00 for ipsec@ietf.org; Thu, 06 May 2004 06:01:31 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLfg4-0000nF-00 for ipsec@ietf.org; Thu, 06 May 2004 06:00:28 -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 i469xNv04303 for ; Thu, 6 May 2004 05:59:26 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i469vmes025478 for ; Thu, 6 May 2004 05:57:48 -0400 (EDT) Received: from xenon2.um.es(155.54.212.101) by nutshell.tislabs.com via csmap (V6.0) id srcAAAeba4QX; Thu, 6 May 04 05:57:28 -0400 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C052F58E3 for ; Thu, 6 May 2004 11:59:50 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id AA9554BA2 for ; Thu, 6 May 2004 11:59:50 +0200 (CEST) Received: from dif.um.es (alborada.dif.um.es [155.54.210.32]) by aries.dif.um.es (Postfix) with ESMTP id 580A314426 for ; Thu, 6 May 2004 11:59:14 +0200 (MET DST) Message-ID: <409A0CB6.C7A3AD27@dif.um.es> Date: Thu, 06 May 2004 12:00:22 +0200 From: "=?iso-8859-1?Q?F=E9lix?= J.=?iso-8859-1?Q?Garc=EDa?= Clemente" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] IKE implementation with authentication using ECDSA? Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello all, Does anybody know any IKE implementation with ECDSA support? Thanks, F=E9lix _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 6 06:24:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03757 for ; Thu, 6 May 2004 06:24:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLg13-0003Yd-U6 for ipsec-archive@odin.ietf.org; Thu, 06 May 2004 06:22:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46AM9EX013665 for ipsec-archive@odin.ietf.org; Thu, 6 May 2004 06:22:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfxf-0002GE-Ht for ipsec-web-archive@optimus.ietf.org; Thu, 06 May 2004 06:18:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03177 for ; Thu, 6 May 2004 06:18:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfxb-0007k6-PQ for ipsec-web-archive@ietf.org; Thu, 06 May 2004 06:18:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfwm-0007NF-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 06:17:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLfw1-0006yi-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 06:16:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfqI-0006gC-PO; Thu, 06 May 2004 06:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfiE-0002gN-3c for ipsec@optimus.ietf.org; Thu, 06 May 2004 06:02:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02482 for ; Thu, 6 May 2004 06:02:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfiA-0001ae-E2 for ipsec@ietf.org; Thu, 06 May 2004 06:02:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfh5-0001CA-00 for ipsec@ietf.org; Thu, 06 May 2004 06:01:31 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLfg4-0000nF-00 for ipsec@ietf.org; Thu, 06 May 2004 06:00:28 -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 i469xNv04303 for ; Thu, 6 May 2004 05:59:26 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i469vmes025478 for ; Thu, 6 May 2004 05:57:48 -0400 (EDT) Received: from xenon2.um.es(155.54.212.101) by nutshell.tislabs.com via csmap (V6.0) id srcAAAeba4QX; Thu, 6 May 04 05:57:28 -0400 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C052F58E3 for ; Thu, 6 May 2004 11:59:50 +0200 (CEST) Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id AA9554BA2 for ; Thu, 6 May 2004 11:59:50 +0200 (CEST) Received: from dif.um.es (alborada.dif.um.es [155.54.210.32]) by aries.dif.um.es (Postfix) with ESMTP id 580A314426 for ; Thu, 6 May 2004 11:59:14 +0200 (MET DST) Message-ID: <409A0CB6.C7A3AD27@dif.um.es> Date: Thu, 06 May 2004 12:00:22 +0200 From: "=?iso-8859-1?Q?F=E9lix?= J.=?iso-8859-1?Q?Garc=EDa?= Clemente" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] IKE implementation with authentication using ECDSA? Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello all, Does anybody know any IKE implementation with ECDSA support? Thanks, F=E9lix _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 6 09:58:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13708 for ; Thu, 6 May 2004 09:58:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjEI-0002Ps-3m; Thu, 06 May 2004 09:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjAL-0000m1-BG for ipsec@optimus.ietf.org; Thu, 06 May 2004 09:43:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12583 for ; Thu, 6 May 2004 09:43:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjAJ-0003oW-Dz for ipsec@ietf.org; Thu, 06 May 2004 09:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLj9F-0003LR-00 for ipsec@ietf.org; Thu, 06 May 2004 09:42:50 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLj8G-0002vN-00 for ipsec@ietf.org; Thu, 06 May 2004 09:41: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 i46Defv21439 for ; Thu, 6 May 2004 09:40:41 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i46Dcq5T002601 for ; Thu, 6 May 2004 09:38:53 -0400 (EDT) Received: from postman-pat.actimage.net(80.87.224.5) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5xaqRe; Thu, 6 May 04 09:37:43 -0400 Received: from Offspring (inet-gate6 [62.157.88.206]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i46Dc8m23298; Thu, 6 May 2004 15:38:09 +0200 (CEST) Message-ID: <038f01c4336f$bfc32440$3c08a8c0@Offspring> From: "Rajive COUNTCHAM" To: , , Cc: Date: Thu, 6 May 2004 15:40:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038A_01C43380.7F603B20" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] Interoperability Plugtests Event Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_038A_01C43380.7F603B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear List, as many of you already know, an interoperability plugtests event in the = field of security will soon take place between the 24th and the 28th of = may in Sophia Antipolis (France). This event is organised by the ETSI = (European Telecommunication Standards Insitute) which is a non-lucrative = organization. PKI, XaDES but also IKE interoperability and standard conformance tests = will be made during this week. It's a unique opportunity for you to test = the validity of one of your product or in a neutral place. Thanks to the = participants, PKI and XaDES will be well represented but I'm surprised = at the few number of participants who will come for IKE.=20 Nortel Networks and Panasonic are already registered and want to test = respectively the interoperability of an IKEv2 partial prototype = implementation and of an IKEv1 product. The deadline is coming very soon and I'm sure that many of you can = benefit from a participation to this event, so I hope you will think = about registering the event seriously. I really encourage you to go to the website : = http://www.etsi.org/Plugtests/security.htm, there, you will find more = information. I would like to know if you will participate. If you have any question, if you need more information, don't hesitate = to contact us. Thanks in advance,=20 =20 Best regards, =20 Rajive Countcham ETSI Consultant -------------------------------- interop@actimage.net +49 7851 899 730 ------=_NextPart_000_038A_01C43380.7F603B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear List,
 
as many of you already know, an=20 interoperability plugtests event in the field of security will soon take = place=20 between the 24th and the 28th of may in Sophia Antipolis (France). This = event is=20 organised by the ETSI (European Telecommunication Standards Insitute) = which is a=20 non-lucrative organization.
PKI, XaDES but also IKE = interoperability and=20 standard conformance tests will be made during this week. It's a unique opportunity for you to test the = validity of=20 one of your product or in a neutral place. Thanks to the participants, = PKI and=20 XaDES will be well represented but I'm surprised at the few number of=20 participants who will come for IKE. 
Nortel Networks and Panasonic are = already=20 registered and want to test respectively the interoperability of an = IKEv2=20 partial prototype implementation and of an IKEv1 product.
The deadline is coming very soon and = I'm sure that=20 many of you can benefit from a participation to this event, so I = hope you=20 will think about registering the event seriously.
 

I really encourage you to go to the website : http://www.etsi.org/P= lugtests/security.htm, = there, you will find more=20 information.

 

I would=20 like to know if you will participate.

If you=20 have any question, if you need more information, don=92t hesitate to = contact=20 us.

Thanks in = advance, 

 

Best=20 regards,

 

Rajive=20 Countcham

ETSI=20 Consultant

--------------------------------

interop@actimage.net

+49 7851=20 899 730

------=_NextPart_000_038A_01C43380.7F603B20-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 6 10:00:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13900 for ; Thu, 6 May 2004 10:00:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjFF-00031a-Rn; Thu, 06 May 2004 09:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjAb-0000md-CM for ipsec@optimus.ietf.org; Thu, 06 May 2004 09:44:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12629 for ; Thu, 6 May 2004 09:44:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjAZ-0003qj-4W for ipsec@ietf.org; Thu, 06 May 2004 09:44:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLj9U-0003O2-00 for ipsec@ietf.org; Thu, 06 May 2004 09:43:05 -0400 Received: from postman-pat.actimage.net ([80.87.224.5] helo=postman-pat.actimage.fr) by ietf-mx with esmtp (Exim 4.12) id 1BLj8h-0002uu-00 for ipsec@ietf.org; Thu, 06 May 2004 09:42:16 -0400 Received: from Offspring (inet-gate6 [62.157.88.206]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i46Dc8m23298; Thu, 6 May 2004 15:38:09 +0200 (CEST) Message-ID: <038f01c4336f$bfc32440$3c08a8c0@Offspring> From: "Rajive COUNTCHAM" To: , , Cc: Date: Thu, 6 May 2004 15:40:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038A_01C43380.7F603B20" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] Interoperability Plugtests Event Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_038A_01C43380.7F603B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear List, as many of you already know, an interoperability plugtests event in the = field of security will soon take place between the 24th and the 28th of = may in Sophia Antipolis (France). This event is organised by the ETSI = (European Telecommunication Standards Insitute) which is a non-lucrative = organization. PKI, XaDES but also IKE interoperability and standard conformance tests = will be made during this week. It's a unique opportunity for you to test = the validity of one of your product or in a neutral place. Thanks to the = participants, PKI and XaDES will be well represented but I'm surprised = at the few number of participants who will come for IKE.=20 Nortel Networks and Panasonic are already registered and want to test = respectively the interoperability of an IKEv2 partial prototype = implementation and of an IKEv1 product. The deadline is coming very soon and I'm sure that many of you can = benefit from a participation to this event, so I hope you will think = about registering the event seriously. I really encourage you to go to the website : = http://www.etsi.org/Plugtests/security.htm, there, you will find more = information. I would like to know if you will participate. If you have any question, if you need more information, don't hesitate = to contact us. Thanks in advance,=20 =20 Best regards, =20 Rajive Countcham ETSI Consultant -------------------------------- interop@actimage.net +49 7851 899 730 ------=_NextPart_000_038A_01C43380.7F603B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear List,
 
as many of you already know, an=20 interoperability plugtests event in the field of security will soon take = place=20 between the 24th and the 28th of may in Sophia Antipolis (France). This = event is=20 organised by the ETSI (European Telecommunication Standards Insitute) = which is a=20 non-lucrative organization.
PKI, XaDES but also IKE = interoperability and=20 standard conformance tests will be made during this week. It's a unique opportunity for you to test the = validity of=20 one of your product or in a neutral place. Thanks to the participants, = PKI and=20 XaDES will be well represented but I'm surprised at the few number of=20 participants who will come for IKE. 
Nortel Networks and Panasonic are = already=20 registered and want to test respectively the interoperability of an = IKEv2=20 partial prototype implementation and of an IKEv1 product.
The deadline is coming very soon and = I'm sure that=20 many of you can benefit from a participation to this event, so I = hope you=20 will think about registering the event seriously.
 

I really encourage you to go to the website : http://www.etsi.org/P= lugtests/security.htm, = there, you will find more=20 information.

 

I would=20 like to know if you will participate.

If you=20 have any question, if you need more information, don=92t hesitate to = contact=20 us.

Thanks in = advance, 

 

Best=20 regards,

 

Rajive=20 Countcham

ETSI=20 Consultant

--------------------------------

interop@actimage.net

+49 7851=20 899 730

------=_NextPart_000_038A_01C43380.7F603B20-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 6 10:14:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15519 for ; Thu, 6 May 2004 10:14:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjVy-0003ae-5j for ipsec-archive@odin.ietf.org; Thu, 06 May 2004 10:06:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46E6INZ013796 for ipsec-archive@odin.ietf.org; Thu, 6 May 2004 10:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjPp-0006wJ-Ld for ipsec-web-archive@optimus.ietf.org; Thu, 06 May 2004 09:59:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13837 for ; Thu, 6 May 2004 09:59:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjPn-0003GI-O5 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 09:59:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjOn-0002mY-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 09:58:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLjNn-0002Ko-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 09:57:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjEI-0002Ps-3m; Thu, 06 May 2004 09:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjAL-0000m1-BG for ipsec@optimus.ietf.org; Thu, 06 May 2004 09:43:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12583 for ; Thu, 6 May 2004 09:43:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjAJ-0003oW-Dz for ipsec@ietf.org; Thu, 06 May 2004 09:43:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLj9F-0003LR-00 for ipsec@ietf.org; Thu, 06 May 2004 09:42:50 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLj8G-0002vN-00 for ipsec@ietf.org; Thu, 06 May 2004 09:41: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 i46Defv21439 for ; Thu, 6 May 2004 09:40:41 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i46Dcq5T002601 for ; Thu, 6 May 2004 09:38:53 -0400 (EDT) Received: from postman-pat.actimage.net(80.87.224.5) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5xaqRe; Thu, 6 May 04 09:37:43 -0400 Received: from Offspring (inet-gate6 [62.157.88.206]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i46Dc8m23298; Thu, 6 May 2004 15:38:09 +0200 (CEST) Message-ID: <038f01c4336f$bfc32440$3c08a8c0@Offspring> From: "Rajive COUNTCHAM" To: , , Cc: Date: Thu, 6 May 2004 15:40:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038A_01C43380.7F603B20" 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 Subject: [Ipsec] Interoperability Plugtests Event Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_038A_01C43380.7F603B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear List, as many of you already know, an interoperability plugtests event in the = field of security will soon take place between the 24th and the 28th of = may in Sophia Antipolis (France). This event is organised by the ETSI = (European Telecommunication Standards Insitute) which is a non-lucrative = organization. PKI, XaDES but also IKE interoperability and standard conformance tests = will be made during this week. It's a unique opportunity for you to test = the validity of one of your product or in a neutral place. Thanks to the = participants, PKI and XaDES will be well represented but I'm surprised = at the few number of participants who will come for IKE.=20 Nortel Networks and Panasonic are already registered and want to test = respectively the interoperability of an IKEv2 partial prototype = implementation and of an IKEv1 product. The deadline is coming very soon and I'm sure that many of you can = benefit from a participation to this event, so I hope you will think = about registering the event seriously. I really encourage you to go to the website : = http://www.etsi.org/Plugtests/security.htm, there, you will find more = information. I would like to know if you will participate. If you have any question, if you need more information, don't hesitate = to contact us. Thanks in advance,=20 =20 Best regards, =20 Rajive Countcham ETSI Consultant -------------------------------- interop@actimage.net +49 7851 899 730 ------=_NextPart_000_038A_01C43380.7F603B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear List,
 
as many of you already know, an=20 interoperability plugtests event in the field of security will soon take = place=20 between the 24th and the 28th of may in Sophia Antipolis (France). This = event is=20 organised by the ETSI (European Telecommunication Standards Insitute) = which is a=20 non-lucrative organization.
PKI, XaDES but also IKE = interoperability and=20 standard conformance tests will be made during this week. It's a unique opportunity for you to test the = validity of=20 one of your product or in a neutral place. Thanks to the participants, = PKI and=20 XaDES will be well represented but I'm surprised at the few number of=20 participants who will come for IKE. 
Nortel Networks and Panasonic are = already=20 registered and want to test respectively the interoperability of an = IKEv2=20 partial prototype implementation and of an IKEv1 product.
The deadline is coming very soon and = I'm sure that=20 many of you can benefit from a participation to this event, so I = hope you=20 will think about registering the event seriously.
 

I really encourage you to go to the website : http://www.etsi.org/P= lugtests/security.htm, = there, you will find more=20 information.

 

I would=20 like to know if you will participate.

If you=20 have any question, if you need more information, don=92t hesitate to = contact=20 us.

Thanks in = advance, 

 

Best=20 regards,

 

Rajive=20 Countcham

ETSI=20 Consultant

--------------------------------

interop@actimage.net

+49 7851=20 899 730

------=_NextPart_000_038A_01C43380.7F603B20-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 6 10:16:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15803 for ; Thu, 6 May 2004 10:16:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjXn-0005EW-9B for ipsec-archive@odin.ietf.org; Thu, 06 May 2004 10:08:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46E8BvZ020109 for ipsec-archive@odin.ietf.org; Thu, 6 May 2004 10:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjRf-0000Zl-Rq for ipsec-web-archive@optimus.ietf.org; Thu, 06 May 2004 10:01:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13994 for ; Thu, 6 May 2004 10:01:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjRd-00049L-V1 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 10:01:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjQf-0003hY-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 10:00:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLjPd-0003EI-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 09:59:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjFF-00031a-Rn; Thu, 06 May 2004 09:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjAb-0000md-CM for ipsec@optimus.ietf.org; Thu, 06 May 2004 09:44:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12629 for ; Thu, 6 May 2004 09:44:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjAZ-0003qj-4W for ipsec@ietf.org; Thu, 06 May 2004 09:44:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLj9U-0003O2-00 for ipsec@ietf.org; Thu, 06 May 2004 09:43:05 -0400 Received: from postman-pat.actimage.net ([80.87.224.5] helo=postman-pat.actimage.fr) by ietf-mx with esmtp (Exim 4.12) id 1BLj8h-0002uu-00 for ipsec@ietf.org; Thu, 06 May 2004 09:42:16 -0400 Received: from Offspring (inet-gate6 [62.157.88.206]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i46Dc8m23298; Thu, 6 May 2004 15:38:09 +0200 (CEST) Message-ID: <038f01c4336f$bfc32440$3c08a8c0@Offspring> From: "Rajive COUNTCHAM" To: , , Cc: Date: Thu, 6 May 2004 15:40:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038A_01C43380.7F603B20" 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 Subject: [Ipsec] Interoperability Plugtests Event Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_038A_01C43380.7F603B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear List, as many of you already know, an interoperability plugtests event in the = field of security will soon take place between the 24th and the 28th of = may in Sophia Antipolis (France). This event is organised by the ETSI = (European Telecommunication Standards Insitute) which is a non-lucrative = organization. PKI, XaDES but also IKE interoperability and standard conformance tests = will be made during this week. It's a unique opportunity for you to test = the validity of one of your product or in a neutral place. Thanks to the = participants, PKI and XaDES will be well represented but I'm surprised = at the few number of participants who will come for IKE.=20 Nortel Networks and Panasonic are already registered and want to test = respectively the interoperability of an IKEv2 partial prototype = implementation and of an IKEv1 product. The deadline is coming very soon and I'm sure that many of you can = benefit from a participation to this event, so I hope you will think = about registering the event seriously. I really encourage you to go to the website : = http://www.etsi.org/Plugtests/security.htm, there, you will find more = information. I would like to know if you will participate. If you have any question, if you need more information, don't hesitate = to contact us. Thanks in advance,=20 =20 Best regards, =20 Rajive Countcham ETSI Consultant -------------------------------- interop@actimage.net +49 7851 899 730 ------=_NextPart_000_038A_01C43380.7F603B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear List,
 
as many of you already know, an=20 interoperability plugtests event in the field of security will soon take = place=20 between the 24th and the 28th of may in Sophia Antipolis (France). This = event is=20 organised by the ETSI (European Telecommunication Standards Insitute) = which is a=20 non-lucrative organization.
PKI, XaDES but also IKE = interoperability and=20 standard conformance tests will be made during this week. It's a unique opportunity for you to test the = validity of=20 one of your product or in a neutral place. Thanks to the participants, = PKI and=20 XaDES will be well represented but I'm surprised at the few number of=20 participants who will come for IKE. 
Nortel Networks and Panasonic are = already=20 registered and want to test respectively the interoperability of an = IKEv2=20 partial prototype implementation and of an IKEv1 product.
The deadline is coming very soon and = I'm sure that=20 many of you can benefit from a participation to this event, so I = hope you=20 will think about registering the event seriously.
 

I really encourage you to go to the website : http://www.etsi.org/P= lugtests/security.htm, = there, you will find more=20 information.

 

I would=20 like to know if you will participate.

If you=20 have any question, if you need more information, don=92t hesitate to = contact=20 us.

Thanks in = advance, 

 

Best=20 regards,

 

Rajive=20 Countcham

ETSI=20 Consultant

--------------------------------

interop@actimage.net

+49 7851=20 899 730

------=_NextPart_000_038A_01C43380.7F603B20-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 6 12:22:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25919 for ; Thu, 6 May 2004 12:22:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkvD-0008I5-1A; Thu, 06 May 2004 11:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkmk-0003cd-ON for ipsec@optimus.ietf.org; Thu, 06 May 2004 11:27:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20100; Thu, 6 May 2004 11:27:40 -0400 (EDT) Message-Id: <200405061527.LAA20100@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipsec@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 06 May 2004 11:27:40 -0400 Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-udp-encaps-09.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --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 : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen, et al. Filename : draft-ietf-ipsec-udp-encaps-09.txt Pages : 21 Date : 2004-5-5 This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-09.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-udp-encaps-09.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-udp-encaps-09.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-5-6113419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113419.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 6 13:19:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03344 for ; Thu, 6 May 2004 13:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLls4-0008UJ-Mu; Thu, 06 May 2004 12:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlDH-00023s-Nt for ipsec@optimus.ietf.org; Thu, 06 May 2004 11:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22390 for ; Thu, 6 May 2004 11:55:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLlDG-0006oS-IU for ipsec@ietf.org; Thu, 06 May 2004 11:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlC3-0006HI-00 for ipsec@ietf.org; Thu, 06 May 2004 11:53:51 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLlAq-0005Sf-00 for ipsec@ietf.org; Thu, 06 May 2004 11:52:36 -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 i46FpVv01088 for ; Thu, 6 May 2004 11:51:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i46FmXRl024381 for ; Thu, 6 May 2004 11:48:35 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAA6BaaCV; Thu, 6 May 04 11:47:59 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46FnjJ08105; Thu, 6 May 2004 08:49:45 -0700 (PDT) Message-ID: <409A5F18.3080600@isi.edu> Date: Thu, 06 May 2004 08:51:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec mailingList X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E0D9B8F8A009B4588F14EDC" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] new internet draftt - draft-touch-anonsec Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E0D9B8F8A009B4588F14EDC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, The following I-D is soon to appear in the drafts directory; until then, here is the title and abstract, and it is available now at: http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt At this time, I'm soliciting discussion and feedback on both TCPM and IPsec mailing lists, where discussion of the issues of IPsec have been ongoing. I track both lists; please do NOT cross-post. I'll cross-summarize periodically if it proves necessary. I'd also like to solicit input on in which WG to proceed. Joe ---- ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks draft-touch-anonsec Recent attacks on core Internet infrastructure indicate an increased vulnerability of TCP connections to spurious resets (RSTs). TCP has always been susceptible to such RST spoof attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can guess a viable RST sequence number. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. Finally, it proposes an extension to IPsec configuration called ANONsec that intends to efficiently and scalably secure any transport protocol from such off-path third-party spoofing attacks. ---- --------------enig5E0D9B8F8A009B4588F14EDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAml8YE5f5cImnZrsRAsYZAJ9Oz0EBcM4fN+d3Y02vVJpVly2zRQCg4DDg IO13SoCIFWm3b45iGDxP1fY= =lYIx -----END PGP SIGNATURE----- --------------enig5E0D9B8F8A009B4588F14EDC-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 6 13:27:50 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04590 for ; Thu, 6 May 2004 13:27:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmP6-00045h-O4 for ipsec-archive@odin.ietf.org; Thu, 06 May 2004 13:11:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HBOd5015720 for ipsec-archive@odin.ietf.org; Thu, 6 May 2004 13:11:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlnY-0005AM-OV for ipsec-web-archive@optimus.ietf.org; Thu, 06 May 2004 12:32:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27273 for ; Thu, 6 May 2004 12:32:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLlnX-0006NT-Cg for ipsec-web-archive@ietf.org; Thu, 06 May 2004 12:32:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLljP-000515-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 12:28:20 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLlhN-00043a-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 12:26:13 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLld2-0001Kp-Ci for ipsec-web-archive@ietf.org; Thu, 06 May 2004 12:21:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkvD-0008I5-1A; Thu, 06 May 2004 11:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkmk-0003cd-ON for ipsec@optimus.ietf.org; Thu, 06 May 2004 11:27:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20100; Thu, 6 May 2004 11:27:40 -0400 (EDT) Message-Id: <200405061527.LAA20100@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipsec@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 06 May 2004 11:27:40 -0400 Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-udp-encaps-09.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen, et al. Filename : draft-ietf-ipsec-udp-encaps-09.txt Pages : 21 Date : 2004-5-5 This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-09.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-udp-encaps-09.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-udp-encaps-09.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-5-6113419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113419.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 6 13:52:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07185 for ; Thu, 6 May 2004 13:52:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmlU-0003WG-9E for ipsec-archive@odin.ietf.org; Thu, 06 May 2004 13:34:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HYWUL013529 for ipsec-archive@odin.ietf.org; Thu, 6 May 2004 13:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmZX-0003kA-F0 for ipsec-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:22:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03734 for ; Thu, 6 May 2004 13:22:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLmZV-00049u-IE for ipsec-web-archive@ietf.org; Thu, 06 May 2004 13:22:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmY1-0003Ik-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 13:20:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLmWP-0002hc-00 for ipsec-web-archive@ietf.org; Thu, 06 May 2004 13:18:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLls4-0008UJ-Mu; Thu, 06 May 2004 12:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlDH-00023s-Nt for ipsec@optimus.ietf.org; Thu, 06 May 2004 11:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22390 for ; Thu, 6 May 2004 11:55:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLlDG-0006oS-IU for ipsec@ietf.org; Thu, 06 May 2004 11:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlC3-0006HI-00 for ipsec@ietf.org; Thu, 06 May 2004 11:53:51 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BLlAq-0005Sf-00 for ipsec@ietf.org; Thu, 06 May 2004 11:52:36 -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 i46FpVv01088 for ; Thu, 6 May 2004 11:51:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i46FmXRl024381 for ; Thu, 6 May 2004 11:48:35 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAA6BaaCV; Thu, 6 May 04 11:47:59 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46FnjJ08105; Thu, 6 May 2004 08:49:45 -0700 (PDT) Message-ID: <409A5F18.3080600@isi.edu> Date: Thu, 06 May 2004 08:51:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec mailingList X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E0D9B8F8A009B4588F14EDC" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [Ipsec] new internet draftt - draft-touch-anonsec Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E0D9B8F8A009B4588F14EDC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, all, The following I-D is soon to appear in the drafts directory; until then, here is the title and abstract, and it is available now at: http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt At this time, I'm soliciting discussion and feedback on both TCPM and IPsec mailing lists, where discussion of the issues of IPsec have been ongoing. I track both lists; please do NOT cross-post. I'll cross-summarize periodically if it proves necessary. I'd also like to solicit input on in which WG to proceed. Joe ---- ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks draft-touch-anonsec Recent attacks on core Internet infrastructure indicate an increased vulnerability of TCP connections to spurious resets (RSTs). TCP has always been susceptible to such RST spoof attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can guess a viable RST sequence number. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. Finally, it proposes an extension to IPsec configuration called ANONsec that intends to efficiently and scalably secure any transport protocol from such off-path third-party spoofing attacks. ---- --------------enig5E0D9B8F8A009B4588F14EDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAml8YE5f5cImnZrsRAsYZAJ9Oz0EBcM4fN+d3Y02vVJpVly2zRQCg4DDg IO13SoCIFWm3b45iGDxP1fY= =lYIx -----END PGP SIGNATURE----- --------------enig5E0D9B8F8A009B4588F14EDC-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 10:20:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25050 for ; Fri, 7 May 2004 10:20:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5uD-0007tu-19; Fri, 07 May 2004 10:00:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM2SL-0006Jl-EH for ipsec@optimus.ietf.org; Fri, 07 May 2004 06:19:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13720 for ; Fri, 7 May 2004 06:19:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM2SH-0000XU-Il for ipsec@ietf.org; Fri, 07 May 2004 06:19:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM2RN-00005x-00 for ipsec@ietf.org; Fri, 07 May 2004 06:18:49 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BM2QI-00072D-00 for ipsec@ietf.org; Fri, 07 May 2004 06:17:42 -0400 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i47AHCEP013455 for ; Fri, 7 May 2004 12:17:13 +0200 Received: from vies194a.sie.siemens.at (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i47AHCSQ032714 for ; Fri, 7 May 2004 12:17:12 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 7 May 2004 12:17:29 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AB86@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPsec WG (E-mail)" Date: Fri, 7 May 2004 12:14:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] VPN remote host configuration IPv6 ? Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable For IPv6 I could not find any standardized methods for Ipsec-tunnel remote-host configuration of RAC=B4s Ipv6-Address etc.=20 in any RFC or draft except IKEv2 configuration payload. In theory DHCPv6 or Autoconfiguration could=20 work too, but no document mentions them. Am I right ? Best regards Peter _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 10:55:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28862 for ; Fri, 7 May 2004 10:55:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6a3-0004gA-HW for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 10:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Ei3nJ017980 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 10:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6Eh-0003Ug-Qe for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:21:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25216 for ; Fri, 7 May 2004 10:21:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6Ef-0002Bq-H6 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 10:21:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6Du-0001kr-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 10:21:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM6DE-0001IU-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 10:20:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5uD-0007tu-19; Fri, 07 May 2004 10:00:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM2SL-0006Jl-EH for ipsec@optimus.ietf.org; Fri, 07 May 2004 06:19:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13720 for ; Fri, 7 May 2004 06:19:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM2SH-0000XU-Il for ipsec@ietf.org; Fri, 07 May 2004 06:19:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM2RN-00005x-00 for ipsec@ietf.org; Fri, 07 May 2004 06:18:49 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BM2QI-00072D-00 for ipsec@ietf.org; Fri, 07 May 2004 06:17:42 -0400 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i47AHCEP013455 for ; Fri, 7 May 2004 12:17:13 +0200 Received: from vies194a.sie.siemens.at (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i47AHCSQ032714 for ; Fri, 7 May 2004 12:17:12 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 7 May 2004 12:17:29 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AB86@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPsec WG (E-mail)" Date: Fri, 7 May 2004 12:14:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] VPN remote host configuration IPv6 ? Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable For IPv6 I could not find any standardized methods for Ipsec-tunnel remote-host configuration of RAC=B4s Ipv6-Address etc.=20 in any RFC or draft except IKEv2 configuration payload. In theory DHCPv6 or Autoconfiguration could=20 work too, but no document mentions them. Am I right ? Best regards Peter _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 11:30:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01352 for ; Fri, 7 May 2004 11:30:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM778-0001aS-Mu; Fri, 07 May 2004 11:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6ls-0000lv-Dx for ipsec@optimus.ietf.org; Fri, 07 May 2004 10:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28934 for ; Fri, 7 May 2004 10:56:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6lp-0002q3-Nz for ipsec@ietf.org; Fri, 07 May 2004 10:56:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6l1-0002Nt-00 for ipsec@ietf.org; Fri, 07 May 2004 10:55:23 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1BM6k7-0001oQ-00 for ipsec@ietf.org; Fri, 07 May 2004 10:54:27 -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 i47ErXg24454; Fri, 7 May 2004 16:53:33 +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 i47ErXSj031917; Fri, 7 May 2004 16:53:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200405071453.i47ErXSj031917@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Grubmair Peter cc: "IPsec WG (E-mail)" Subject: Re: [Ipsec] VPN remote host configuration IPv6 ? In-reply-to: Your message of Fri, 07 May 2004 12:14:14 +0200. <4D50D5110555D5119F270800062B41650532AB86@viee10pa.erd.siemens.at> Date: Fri, 07 May 2004 16:53:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , In your previous mail you wrote: For IPv6 I could not find any standardized methods for Ipsec-tunnel remote-host configuration of RAC´s Ipv6-Address etc. in any RFC or draft except IKEv2 configuration payload. In theory DHCPv6 or Autoconfiguration could work too, but no document mentions them. Am I right ? => your right, MODE-CFG is not a standard and was written when IPsec and IPv6 were on two different planets... My advice is to try L2TP/IPsec (i.e., L2TP protected by IPsec in transport mode) which works with a lot of different protocols under and over it, and is widely supported. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 11:47:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02193 for ; Fri, 7 May 2004 11:47:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM7PW-0007pV-Al for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 11:37:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47FbEHr030098 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 11:37:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM7Kd-0006B4-K9 for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 11:32:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01438 for ; Fri, 7 May 2004 11:32:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM7Kc-0003Ji-MD for ipsec-web-archive@ietf.org; Fri, 07 May 2004 11:32:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM7JU-0002pJ-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 11:31:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM7IS-0002NW-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 11:29:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM778-0001aS-Mu; Fri, 07 May 2004 11:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6ls-0000lv-Dx for ipsec@optimus.ietf.org; Fri, 07 May 2004 10:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28934 for ; Fri, 7 May 2004 10:56:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM6lp-0002q3-Nz for ipsec@ietf.org; Fri, 07 May 2004 10:56:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM6l1-0002Nt-00 for ipsec@ietf.org; Fri, 07 May 2004 10:55:23 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1BM6k7-0001oQ-00 for ipsec@ietf.org; Fri, 07 May 2004 10:54:27 -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 i47ErXg24454; Fri, 7 May 2004 16:53:33 +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 i47ErXSj031917; Fri, 7 May 2004 16:53:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200405071453.i47ErXSj031917@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Grubmair Peter cc: "IPsec WG (E-mail)" Subject: Re: [Ipsec] VPN remote host configuration IPv6 ? In-reply-to: Your message of Fri, 07 May 2004 12:14:14 +0200. <4D50D5110555D5119F270800062B41650532AB86@viee10pa.erd.siemens.at> Date: Fri, 07 May 2004 16:53:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 In your previous mail you wrote: For IPv6 I could not find any standardized methods for Ipsec-tunnel remote-host configuration of RAC´s Ipv6-Address etc. in any RFC or draft except IKEv2 configuration payload. In theory DHCPv6 or Autoconfiguration could work too, but no document mentions them. Am I right ? => your right, MODE-CFG is not a standard and was written when IPsec and IPv6 were on two different planets... My advice is to try L2TP/IPsec (i.e., L2TP protected by IPsec in transport mode) which works with a lot of different protocols under and over it, and is widely supported. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 12:59:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05490 for ; Fri, 7 May 2004 12:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8Zu-0007xA-Nc; Fri, 07 May 2004 12:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8QA-0004pG-1m for ipsec@optimus.ietf.org; Fri, 07 May 2004 12:41:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04510 for ; Fri, 7 May 2004 12:41:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM8Q8-0002xh-Eu for ipsec@ietf.org; Fri, 07 May 2004 12:41:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8P9-0002Uk-00 for ipsec@ietf.org; Fri, 07 May 2004 12:40:56 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM8OF-00023Q-00 for ipsec@ietf.org; Fri, 07 May 2004 12:39:59 -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 i47Gcq822612 for ; Fri, 7 May 2004 12:38:52 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47GbSwD016602 for ; Fri, 7 May 2004 12:37:28 -0400 (EDT) Received: from ams-iport-1.cisco.com(144.254.224.140) by nutshell.tislabs.com via csmap (V6.0) id srcAAALwayqG; Fri, 7 May 04 12:37:00 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 May 2004 18:48:48 +0200 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47GdHbj011566; Fri, 7 May 2004 18:39:18 +0200 (MEST) Received: from boraw2k03 (rtp-vpn3-510.cisco.com [10.82.218.1]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOT18374; Fri, 7 May 2004 09:39:15 -0700 (PDT) From: "Bora Akyol" To: "'Joe Touch'" , "'ipsec mailingList'" Subject: RE: [Ipsec] new internet draftt - draft-touch-anonsec Date: Fri, 7 May 2004 09:39:38 -0700 Message-ID: <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> 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, Build 10.0.4024 In-Reply-To: <409A5F18.3080600@isi.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joe What is the difference between AnonIKE and having the same pre-shared key (as in preshared_key ="anonIKE") in all of the points of interest? I think this would get you the same effect. I also fail to see what is so scary about adding the ACK response to RST to TCP as described in tcpm draft that came out. Your argument in the draft does not actually show a fundamental problem with this approach. Finally, as is widely discussed, IKEv1 is not the most robust protocol as far as responsiveness to DOS attacks. By requiring these nodes to do IKE, I think we would opening ourselves up for more problems. Regards, Bora _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 13:12:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06262 for ; Fri, 7 May 2004 13:12:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8nf-0004Jh-GP for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 13:06:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47H6FKp016594 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 13:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8iY-0002Yp-E1 for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 13:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05643 for ; Fri, 7 May 2004 13:00:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM8iW-0003iB-Me for ipsec-web-archive@ietf.org; Fri, 07 May 2004 13:00:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8hg-0003GB-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 13:00:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM8gk-0002ne-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 12:59:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8Zu-0007xA-Nc; Fri, 07 May 2004 12:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8QA-0004pG-1m for ipsec@optimus.ietf.org; Fri, 07 May 2004 12:41:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04510 for ; Fri, 7 May 2004 12:41:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM8Q8-0002xh-Eu for ipsec@ietf.org; Fri, 07 May 2004 12:41:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8P9-0002Uk-00 for ipsec@ietf.org; Fri, 07 May 2004 12:40:56 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM8OF-00023Q-00 for ipsec@ietf.org; Fri, 07 May 2004 12:39:59 -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 i47Gcq822612 for ; Fri, 7 May 2004 12:38:52 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47GbSwD016602 for ; Fri, 7 May 2004 12:37:28 -0400 (EDT) Received: from ams-iport-1.cisco.com(144.254.224.140) by nutshell.tislabs.com via csmap (V6.0) id srcAAALwayqG; Fri, 7 May 04 12:37:00 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 May 2004 18:48:48 +0200 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47GdHbj011566; Fri, 7 May 2004 18:39:18 +0200 (MEST) Received: from boraw2k03 (rtp-vpn3-510.cisco.com [10.82.218.1]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOT18374; Fri, 7 May 2004 09:39:15 -0700 (PDT) From: "Bora Akyol" To: "'Joe Touch'" , "'ipsec mailingList'" Subject: RE: [Ipsec] new internet draftt - draft-touch-anonsec Date: Fri, 7 May 2004 09:39:38 -0700 Message-ID: <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> 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, Build 10.0.4024 In-Reply-To: <409A5F18.3080600@isi.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe What is the difference between AnonIKE and having the same pre-shared key (as in preshared_key ="anonIKE") in all of the points of interest? I think this would get you the same effect. I also fail to see what is so scary about adding the ACK response to RST to TCP as described in tcpm draft that came out. Your argument in the draft does not actually show a fundamental problem with this approach. Finally, as is widely discussed, IKEv1 is not the most robust protocol as far as responsiveness to DOS attacks. By requiring these nodes to do IKE, I think we would opening ourselves up for more problems. Regards, Bora _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 13:40:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07986 for ; Fri, 7 May 2004 13:40:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9Cb-00042Y-3u; Fri, 07 May 2004 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM97n-0002cf-Ai for ipsec@optimus.ietf.org; Fri, 07 May 2004 13:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07361 for ; Fri, 7 May 2004 13:27:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM97l-0000Bm-B3 for ipsec@ietf.org; Fri, 07 May 2004 13:27:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM96n-0007WW-00 for ipsec@ietf.org; Fri, 07 May 2004 13:26:01 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM95b-0006tf-00 for ipsec@ietf.org; Fri, 07 May 2004 13:24:47 -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 i47HNa826840 for ; Fri, 7 May 2004 13:23:37 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47HLsYQ024046 for ; Fri, 7 May 2004 13:21:54 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfWaW7U; Fri, 7 May 04 13:21:49 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47HKwJ06363; Fri, 7 May 2004 10:20:58 -0700 (PDT) Message-ID: <409BC579.9070904@isi.edu> Date: Fri, 07 May 2004 10:20:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bora Akyol CC: "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec References: <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> In-Reply-To: <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5CB25124BD11C51624F9551" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5CB25124BD11C51624F9551 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bora Akyol wrote: > Joe > > What is the difference between AnonIKE and having the same > pre-shared key (as in preshared_key ="anonIKE") in all of the points of > interest? That's something we're looking into. Far as I can tell right now, using unauthenticated certificates (i.e., where the CA isn't checked) is equivalent to a longer nonce. There may be some value to using a longer nonce - I don't know enough about the diffie-hellman exchange to determine that. Otherwise, though, they should be equivalent. > I think this would get you the same effect. I also fail to see what is > so scary about adding the ACK response to RST to TCP as described in > tcpm draft that came out. Your argument in the draft does not > actually show a fundamental problem with this approach. The draft is not intended to go into that level of detail, but to refer to discussions on the TCPM mailing list which will hopefully go into an update of the RST-modification draft. One concern is a RST ACK storm. A RST is intended to be a unilateral connection abort; replying to that sort of thing, depending on the state of the source, can cause oscillation. > Finally, as is widely discussed, IKEv1 is not the most robust protocol > as far as responsiveness to DOS attacks. By requiring these nodes to do > IKE, I think we would opening ourselves up for more problems. > > Regards, > > Bora I don't appreciate enough of the details between IKEv1 and IKEv2 to understand whether that would solve the problem. I would presume that IKE would be rate-limited, i.e., the same way SYN processing is for TCP, to protect new association requests from assaulting existing associations. Is that the issue with DOS for IKEv1, or is there something more specific? Joe --------------enigD5CB25124BD11C51624F9551 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAm8V5E5f5cImnZrsRAitvAKCgGdFeCAidpvQhyT/GB8XRYxDXmACfcEbo CP6TAEd41jxYGQHDyOJyNEo= =t52X -----END PGP SIGNATURE----- --------------enigD5CB25124BD11C51624F9551-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 13:47:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08430 for ; Fri, 7 May 2004 13:47:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9M2-0007Ji-QI for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 13:41:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47HfkKQ028121 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 13:41:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9LX-0006zp-RQ for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 13:41:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08103 for ; Fri, 7 May 2004 13:41:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9LV-0006Nz-Gl for ipsec-web-archive@ietf.org; Fri, 07 May 2004 13:41:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9KZ-0005va-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 13:40:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM9Jw-0005Ta-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 13:39:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9Cb-00042Y-3u; Fri, 07 May 2004 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM97n-0002cf-Ai for ipsec@optimus.ietf.org; Fri, 07 May 2004 13:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07361 for ; Fri, 7 May 2004 13:27:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM97l-0000Bm-B3 for ipsec@ietf.org; Fri, 07 May 2004 13:27:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM96n-0007WW-00 for ipsec@ietf.org; Fri, 07 May 2004 13:26:01 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM95b-0006tf-00 for ipsec@ietf.org; Fri, 07 May 2004 13:24:47 -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 i47HNa826840 for ; Fri, 7 May 2004 13:23:37 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47HLsYQ024046 for ; Fri, 7 May 2004 13:21:54 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfWaW7U; Fri, 7 May 04 13:21:49 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47HKwJ06363; Fri, 7 May 2004 10:20:58 -0700 (PDT) Message-ID: <409BC579.9070904@isi.edu> Date: Fri, 07 May 2004 10:20:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bora Akyol CC: "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec References: <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> In-Reply-To: <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5CB25124BD11C51624F9551" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5CB25124BD11C51624F9551 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bora Akyol wrote: > Joe > > What is the difference between AnonIKE and having the same > pre-shared key (as in preshared_key ="anonIKE") in all of the points of > interest? That's something we're looking into. Far as I can tell right now, using unauthenticated certificates (i.e., where the CA isn't checked) is equivalent to a longer nonce. There may be some value to using a longer nonce - I don't know enough about the diffie-hellman exchange to determine that. Otherwise, though, they should be equivalent. > I think this would get you the same effect. I also fail to see what is > so scary about adding the ACK response to RST to TCP as described in > tcpm draft that came out. Your argument in the draft does not > actually show a fundamental problem with this approach. The draft is not intended to go into that level of detail, but to refer to discussions on the TCPM mailing list which will hopefully go into an update of the RST-modification draft. One concern is a RST ACK storm. A RST is intended to be a unilateral connection abort; replying to that sort of thing, depending on the state of the source, can cause oscillation. > Finally, as is widely discussed, IKEv1 is not the most robust protocol > as far as responsiveness to DOS attacks. By requiring these nodes to do > IKE, I think we would opening ourselves up for more problems. > > Regards, > > Bora I don't appreciate enough of the details between IKEv1 and IKEv2 to understand whether that would solve the problem. I would presume that IKE would be rate-limited, i.e., the same way SYN processing is for TCP, to protect new association requests from assaulting existing associations. Is that the issue with DOS for IKEv1, or is there something more specific? Joe --------------enigD5CB25124BD11C51624F9551 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAm8V5E5f5cImnZrsRAitvAKCgGdFeCAidpvQhyT/GB8XRYxDXmACfcEbo CP6TAEd41jxYGQHDyOJyNEo= =t52X -----END PGP SIGNATURE----- --------------enigD5CB25124BD11C51624F9551-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 14:06:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09365 for ; Fri, 7 May 2004 14:06:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9eg-0003ys-SA; Fri, 07 May 2004 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9W8-0001kF-TJ for ipsec@optimus.ietf.org; Fri, 07 May 2004 13:52:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08711 for ; Fri, 7 May 2004 13:52:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9W6-0003Lq-Ft for ipsec@ietf.org; Fri, 07 May 2004 13:52:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9V8-0002uA-00 for ipsec@ietf.org; Fri, 07 May 2004 13:51:11 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM9UT-0002Sk-00 for ipsec@ietf.org; Fri, 07 May 2004 13:50:29 -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 i47HnM828624 for ; Fri, 7 May 2004 13:49:22 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47Hm11H027462 for ; Fri, 7 May 2004 13:48:01 -0400 (EDT) Received: from sj-iport-2-in.cisco.com(171.71.176.71) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhuaqO1; Fri, 7 May 04 13:48:00 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 May 2004 09:53:55 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i47HoOSu019942; Fri, 7 May 2004 10:50:24 -0700 (PDT) Received: from boraw2k03 (rtp-vpn3-510.cisco.com [10.82.218.1]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOT28200; Fri, 7 May 2004 10:50:22 -0700 (PDT) From: "Bora Akyol" To: "'Joe Touch'" Cc: "'ipsec mailingList'" Subject: RE: [Ipsec] new internet draftt - draft-touch-anonsec Date: Fri, 7 May 2004 10:50:45 -0700 Message-ID: <003a01c4345b$d3847c80$050a0a0a@amer.cisco.com> 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, Build 10.0.4024 In-Reply-To: <409BC579.9070904@isi.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Joe I will subscribe to the tcpm list for the details on the RST ACK storm, I guess this could be used as an amplifier for an attack if I understand you correctly. See below for comments on IKE > > Finally, as is widely discussed, IKEv1 is not the most > robust protocol > > as far as responsiveness to DOS attacks. By requiring these > nodes to do > > IKE, I think we would opening ourselves up for more problems. > > > > Regards, > > > > Bora > > I don't appreciate enough of the details between IKEv1 and IKEv2 to > understand whether that would solve the problem. > > I would presume that IKE would be rate-limited, i.e., the > same way SYN > processing is for TCP, to protect new association requests from > assaulting existing associations. Is that the issue with DOS > for IKEv1, > or is there something more specific? > > Joe IKEv1 creates state for each new connection on the first packet, so does IKEv2 unless the cookie option is used which is left as a non-mandatory feature in the draft only to be activated when the system detects its under attack. Due to this, I think moving the security problem down to IKE does not solve it, it just shifts it. Thanks for your comments, Bora _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 14:13:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09750 for ; Fri, 7 May 2004 14:13:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9oG-0007KP-6n for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 14:10:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47IAu5J028165 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 14:10:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9lU-0006Mm-56 for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 14:08:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09508 for ; Fri, 7 May 2004 14:08:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9lR-0002dD-RD for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:08:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9kR-00029b-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:07:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM9jM-0001cA-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:05:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9eg-0003ys-SA; Fri, 07 May 2004 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9W8-0001kF-TJ for ipsec@optimus.ietf.org; Fri, 07 May 2004 13:52:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08711 for ; Fri, 7 May 2004 13:52:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9W6-0003Lq-Ft for ipsec@ietf.org; Fri, 07 May 2004 13:52:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9V8-0002uA-00 for ipsec@ietf.org; Fri, 07 May 2004 13:51:11 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM9UT-0002Sk-00 for ipsec@ietf.org; Fri, 07 May 2004 13:50:29 -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 i47HnM828624 for ; Fri, 7 May 2004 13:49:22 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47Hm11H027462 for ; Fri, 7 May 2004 13:48:01 -0400 (EDT) Received: from sj-iport-2-in.cisco.com(171.71.176.71) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhuaqO1; Fri, 7 May 04 13:48:00 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 May 2004 09:53:55 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i47HoOSu019942; Fri, 7 May 2004 10:50:24 -0700 (PDT) Received: from boraw2k03 (rtp-vpn3-510.cisco.com [10.82.218.1]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOT28200; Fri, 7 May 2004 10:50:22 -0700 (PDT) From: "Bora Akyol" To: "'Joe Touch'" Cc: "'ipsec mailingList'" Subject: RE: [Ipsec] new internet draftt - draft-touch-anonsec Date: Fri, 7 May 2004 10:50:45 -0700 Message-ID: <003a01c4345b$d3847c80$050a0a0a@amer.cisco.com> 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, Build 10.0.4024 In-Reply-To: <409BC579.9070904@isi.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Joe I will subscribe to the tcpm list for the details on the RST ACK storm, I guess this could be used as an amplifier for an attack if I understand you correctly. See below for comments on IKE > > Finally, as is widely discussed, IKEv1 is not the most > robust protocol > > as far as responsiveness to DOS attacks. By requiring these > nodes to do > > IKE, I think we would opening ourselves up for more problems. > > > > Regards, > > > > Bora > > I don't appreciate enough of the details between IKEv1 and IKEv2 to > understand whether that would solve the problem. > > I would presume that IKE would be rate-limited, i.e., the > same way SYN > processing is for TCP, to protect new association requests from > assaulting existing associations. Is that the issue with DOS > for IKEv1, > or is there something more specific? > > Joe IKEv1 creates state for each new connection on the first packet, so does IKEv2 unless the cookie option is used which is left as a non-mandatory feature in the draft only to be activated when the system detects its under attack. Due to this, I think moving the security problem down to IKE does not solve it, it just shifts it. Thanks for your comments, Bora _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 14:18:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09979 for ; Fri, 7 May 2004 14:18:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9oV-0007NC-Fn; Fri, 07 May 2004 14:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9nO-0006oR-Oc for ipsec@optimus.ietf.org; Fri, 07 May 2004 14:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09604 for ; Fri, 7 May 2004 14:09:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9nM-0003UY-AO for ipsec@ietf.org; Fri, 07 May 2004 14:10:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9mS-00034x-00 for ipsec@ietf.org; Fri, 07 May 2004 14:09:05 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM9m3-0002fC-00 for ipsec@ietf.org; Fri, 07 May 2004 14:08:39 -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 i47I7V800604 for ; Fri, 7 May 2004 14:07:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47I67NN029376 for ; Fri, 7 May 2004 14:06:07 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHdayx5; Fri, 7 May 04 14:06:04 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47I6LJ18636; Fri, 7 May 2004 11:06:21 -0700 (PDT) Message-ID: <409BD018.1030504@isi.edu> Date: Fri, 07 May 2004 11:06:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bora Akyol CC: "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec References: <003a01c4345b$d3847c80$050a0a0a@amer.cisco.com> In-Reply-To: <003a01c4345b$d3847c80$050a0a0a@amer.cisco.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA85F4520D611BB56AD657741" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA85F4520D611BB56AD657741 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bora Akyol wrote: ... >>>Finally, as is widely discussed, IKEv1 is not the most >>robust protocol >>>as far as responsiveness to DOS attacks. By requiring these >>nodes to do >>>IKE, I think we would opening ourselves up for more problems. >>> >>>Regards, >>> >>>Bora >> >>I don't appreciate enough of the details between IKEv1 and IKEv2 to >>understand whether that would solve the problem. >> >>I would presume that IKE would be rate-limited, i.e., the >>same way SYN >>processing is for TCP, to protect new association requests from >>assaulting existing associations. Is that the issue with DOS >>for IKEv1, >>or is there something more specific? >> >>Joe > > IKEv1 creates state for each new connection on the first packet, so does > IKEv2 > unless the cookie option is used which is left as a non-mandatory > feature > in the draft only to be activated when the system detects its under > attack. > > Due to this, I think moving the security problem down to IKE does not > solve it, it just shifts it. > > Thanks for your comments, > > Bora Hi, Bora, The revision to the draft will address this in further detail. Some initial thoughts: 1) ANONike costs more in open SPIs and messages, but a lot less in certificate validation costs vs. using a known CA (though as before the difference - if any - between ANONike and preshared fixed keys should be examined further) 2) I heartily agree that this shifts the problem, IMO to a place that ought to be optimized to handle it. I.e., moving it to IKE means we solve it once, at least for attacks from off-path spoofers 3) if you have an on-path attack, you really just have load - notably since I'm assuming you turned on ANONsec because you're running a publicly available service shedding load for public services is also a well-known issue, and certainly needs to be considered. ANONsec helps avoid the off-path attacks, not the on-path from parties willing to setup full associations, either at the IPsec or TCP layers Joe --------------enigA85F4520D611BB56AD657741 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAm9AdE5f5cImnZrsRAtc9AKC2DiLzyTPd3Nvr2aNkjTtD7p5sFwCfc1ZO 5vAMK1287kIYiNFhJNVWi/o= =Kgur -----END PGP SIGNATURE----- --------------enigA85F4520D611BB56AD657741-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 14:25:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10281 for ; Fri, 7 May 2004 14:25:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9w8-0001Ie-9n; Fri, 07 May 2004 14:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9pi-0007fw-BV for ipsec@optimus.ietf.org; Fri, 07 May 2004 14:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09674 for ; Fri, 7 May 2004 14:12:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9pf-0004PN-OF for ipsec@ietf.org; Fri, 07 May 2004 14:12:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9oX-0003wu-00 for ipsec@ietf.org; Fri, 07 May 2004 14:11:14 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM9no-0003VI-00 for ipsec@ietf.org; Fri, 07 May 2004 14:10:28 -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 i47I9J800824 for ; Fri, 7 May 2004 14:09:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47I7tph029748 for ; Fri, 7 May 2004 14:07:55 -0400 (EDT) Received: from oetest.freeswan.org(205.150.200.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAARPaig6; Fri, 7 May 04 14:07:53 -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 i47IABP02142 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 May 2004 14:10:13 -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 i47Hx8E18988 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 May 2004 13:59:13 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47HrCRO005038 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 May 2004 13:53:12 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47HrAOC005035; Fri, 7 May 2004 13:53:10 -0400 To: "Bora Akyol" cc: "'Joe Touch'" , "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec In-Reply-To: Message from "Bora Akyol" of "Fri, 07 May 2004 09:39:38 PDT." <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> References: <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Fri, 07 May 2004 13:53:10 -0400 Message-ID: <5034.1083952390@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , >>>>> "Bora" == Bora Akyol writes: Bora> Finally, as is widely discussed, IKEv1 is not the most robust protocol Bora> as far as responsiveness to DOS attacks. By requiring these nodes to do Bora> IKE, I think we would opening ourselves up for more problems. IKE in aggressive mode has that property. That's why smart people don't use that. -- ] ON HUMILITY: to err is human. To moo, bovine. | 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"); [ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 14:30:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10794 for ; Fri, 7 May 2004 14:30:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMA5S-0003xx-L6 for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 14:28:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47ISgFE015246 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 14:28:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9xF-0001ar-KR for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 14:20:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10124 for ; Fri, 7 May 2004 14:20:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9xD-00004y-6Q for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:20:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9wL-0007RM-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:19:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM9vW-0006zX-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:18:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9oV-0007NC-Fn; Fri, 07 May 2004 14:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9nO-0006oR-Oc for ipsec@optimus.ietf.org; Fri, 07 May 2004 14:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09604 for ; Fri, 7 May 2004 14:09:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9nM-0003UY-AO for ipsec@ietf.org; Fri, 07 May 2004 14:10:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9mS-00034x-00 for ipsec@ietf.org; Fri, 07 May 2004 14:09:05 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM9m3-0002fC-00 for ipsec@ietf.org; Fri, 07 May 2004 14:08:39 -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 i47I7V800604 for ; Fri, 7 May 2004 14:07:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47I67NN029376 for ; Fri, 7 May 2004 14:06:07 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHdayx5; Fri, 7 May 04 14:06:04 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47I6LJ18636; Fri, 7 May 2004 11:06:21 -0700 (PDT) Message-ID: <409BD018.1030504@isi.edu> Date: Fri, 07 May 2004 11:06:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bora Akyol CC: "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec References: <003a01c4345b$d3847c80$050a0a0a@amer.cisco.com> In-Reply-To: <003a01c4345b$d3847c80$050a0a0a@amer.cisco.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA85F4520D611BB56AD657741" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA85F4520D611BB56AD657741 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bora Akyol wrote: ... >>>Finally, as is widely discussed, IKEv1 is not the most >>robust protocol >>>as far as responsiveness to DOS attacks. By requiring these >>nodes to do >>>IKE, I think we would opening ourselves up for more problems. >>> >>>Regards, >>> >>>Bora >> >>I don't appreciate enough of the details between IKEv1 and IKEv2 to >>understand whether that would solve the problem. >> >>I would presume that IKE would be rate-limited, i.e., the >>same way SYN >>processing is for TCP, to protect new association requests from >>assaulting existing associations. Is that the issue with DOS >>for IKEv1, >>or is there something more specific? >> >>Joe > > IKEv1 creates state for each new connection on the first packet, so does > IKEv2 > unless the cookie option is used which is left as a non-mandatory > feature > in the draft only to be activated when the system detects its under > attack. > > Due to this, I think moving the security problem down to IKE does not > solve it, it just shifts it. > > Thanks for your comments, > > Bora Hi, Bora, The revision to the draft will address this in further detail. Some initial thoughts: 1) ANONike costs more in open SPIs and messages, but a lot less in certificate validation costs vs. using a known CA (though as before the difference - if any - between ANONike and preshared fixed keys should be examined further) 2) I heartily agree that this shifts the problem, IMO to a place that ought to be optimized to handle it. I.e., moving it to IKE means we solve it once, at least for attacks from off-path spoofers 3) if you have an on-path attack, you really just have load - notably since I'm assuming you turned on ANONsec because you're running a publicly available service shedding load for public services is also a well-known issue, and certainly needs to be considered. ANONsec helps avoid the off-path attacks, not the on-path from parties willing to setup full associations, either at the IPsec or TCP layers Joe --------------enigA85F4520D611BB56AD657741 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAm9AdE5f5cImnZrsRAtc9AKC2DiLzyTPd3Nvr2aNkjTtD7p5sFwCfc1ZO 5vAMK1287kIYiNFhJNVWi/o= =Kgur -----END PGP SIGNATURE----- --------------enigA85F4520D611BB56AD657741-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 14:43:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11361 for ; Fri, 7 May 2004 14:43:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMACX-0005vg-TE; Fri, 07 May 2004 14:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMA7h-0004h7-No for ipsec@optimus.ietf.org; Fri, 07 May 2004 14:31:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10853 for ; Fri, 7 May 2004 14:30:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMA7f-0004yP-1d for ipsec@ietf.org; Fri, 07 May 2004 14:30:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMA6h-0004Z0-00 for ipsec@ietf.org; Fri, 07 May 2004 14:29:59 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BMA6E-00049g-00 for ipsec@ietf.org; Fri, 07 May 2004 14:29:30 -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 i47ISN803211 for ; Fri, 7 May 2004 14:28:23 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47IR1bC002208 for ; Fri, 7 May 2004 14:27:01 -0400 (EDT) Received: from sj-iport-5.cisco.com(171.68.10.87) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3VaGse; Fri, 7 May 04 14:26:56 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 May 2004 11:29:35 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i47ITKjO018388; Fri, 7 May 2004 11:29:20 -0700 (PDT) Received: from boraw2k03 (rtp-vpn3-510.cisco.com [10.82.218.1]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOT33106; Fri, 7 May 2004 11:29:18 -0700 (PDT) From: "Bora Akyol" To: "'Michael Richardson'" Cc: "'Joe Touch'" , "'ipsec mailingList'" Subject: RE: [Ipsec] new internet draftt - draft-touch-anonsec Date: Fri, 7 May 2004 11:29:42 -0700 Message-ID: <004c01c43461$442a6e40$050a0a0a@amer.cisco.com> 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, Build 10.0.4024 In-Reply-To: <5034.1083952390@marajade.sandelman.ottawa.on.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 1) MM has its own issues coupled with the fact that it takes 6 messages to get anything done. What's next, a MM exchange for each DNS request. 2) If the DOS attacks are coming from machines that are "owned" MM has very similar properties to aggressive mode. 3) IKE for the purpose of off-path transport layer attacks is like using a jack hammer to drive a thin nail on a picture frame. 4) The proposed approach which is really equivalent to a pre-shared key that is hard coded into every IKE implementation opens us up for even more issues. I think the basic idea has merit, i.e. for certain applications the receiver must be in control of who it talks to. I am not sure IKE is the way to go for this. Bora > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Friday, May 07, 2004 10:53 AM > To: Bora Akyol > Cc: 'Joe Touch'; 'ipsec mailingList' > Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec > > > > >>>>> "Bora" == Bora Akyol writes: > Bora> Finally, as is widely discussed, IKEv1 is not the > most robust protocol > Bora> as far as responsiveness to DOS attacks. By > requiring these nodes to do > Bora> IKE, I think we would opening ourselves up for more > problems. > > IKE in aggressive mode has that property. > That's why smart people don't use that. > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 14:57:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12387 for ; Fri, 7 May 2004 14:57:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAVd-0003UB-ED for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 14:55:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47ItjaH013391 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 14:55:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMALD-0000N6-GU for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 14:44:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11587 for ; Fri, 7 May 2004 14:44:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMALA-00039E-RN for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:44:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAJb-0002KU-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:43:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMAI0-0001Tw-02 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:41:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9w8-0001Ie-9n; Fri, 07 May 2004 14:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM9pi-0007fw-BV for ipsec@optimus.ietf.org; Fri, 07 May 2004 14:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09674 for ; Fri, 7 May 2004 14:12:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM9pf-0004PN-OF for ipsec@ietf.org; Fri, 07 May 2004 14:12:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM9oX-0003wu-00 for ipsec@ietf.org; Fri, 07 May 2004 14:11:14 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BM9no-0003VI-00 for ipsec@ietf.org; Fri, 07 May 2004 14:10:28 -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 i47I9J800824 for ; Fri, 7 May 2004 14:09:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47I7tph029748 for ; Fri, 7 May 2004 14:07:55 -0400 (EDT) Received: from oetest.freeswan.org(205.150.200.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAARPaig6; Fri, 7 May 04 14:07:53 -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 i47IABP02142 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 May 2004 14:10:13 -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 i47Hx8E18988 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 May 2004 13:59:13 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47HrCRO005038 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 May 2004 13:53:12 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47HrAOC005035; Fri, 7 May 2004 13:53:10 -0400 To: "Bora Akyol" cc: "'Joe Touch'" , "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec In-Reply-To: Message from "Bora Akyol" of "Fri, 07 May 2004 09:39:38 PDT." <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> References: <002301c43451$e42a76c0$050a0a0a@amer.cisco.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Fri, 07 May 2004 13:53:10 -0400 Message-ID: <5034.1083952390@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> "Bora" == Bora Akyol writes: Bora> Finally, as is widely discussed, IKEv1 is not the most robust protocol Bora> as far as responsiveness to DOS attacks. By requiring these nodes to do Bora> IKE, I think we would opening ourselves up for more problems. IKE in aggressive mode has that property. That's why smart people don't use that. -- ] ON HUMILITY: to err is human. To moo, bovine. | 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"); [ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 14:58:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12478 for ; Fri, 7 May 2004 14:58:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAVf-0003Wm-Nw for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 14:55:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Itl5a013553 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 14:55:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMALj-0000Or-F1 for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 14:45:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11702 for ; Fri, 7 May 2004 14:45:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMALg-0003UW-QU for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:45:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAKb-0002xr-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:44:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMAJ3-00020u-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 14:42:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMACX-0005vg-TE; Fri, 07 May 2004 14:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMA7h-0004h7-No for ipsec@optimus.ietf.org; Fri, 07 May 2004 14:31:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10853 for ; Fri, 7 May 2004 14:30:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMA7f-0004yP-1d for ipsec@ietf.org; Fri, 07 May 2004 14:30:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMA6h-0004Z0-00 for ipsec@ietf.org; Fri, 07 May 2004 14:29:59 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BMA6E-00049g-00 for ipsec@ietf.org; Fri, 07 May 2004 14:29:30 -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 i47ISN803211 for ; Fri, 7 May 2004 14:28:23 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47IR1bC002208 for ; Fri, 7 May 2004 14:27:01 -0400 (EDT) Received: from sj-iport-5.cisco.com(171.68.10.87) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3VaGse; Fri, 7 May 04 14:26:56 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 May 2004 11:29:35 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i47ITKjO018388; Fri, 7 May 2004 11:29:20 -0700 (PDT) Received: from boraw2k03 (rtp-vpn3-510.cisco.com [10.82.218.1]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOT33106; Fri, 7 May 2004 11:29:18 -0700 (PDT) From: "Bora Akyol" To: "'Michael Richardson'" Cc: "'Joe Touch'" , "'ipsec mailingList'" Subject: RE: [Ipsec] new internet draftt - draft-touch-anonsec Date: Fri, 7 May 2004 11:29:42 -0700 Message-ID: <004c01c43461$442a6e40$050a0a0a@amer.cisco.com> 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, Build 10.0.4024 In-Reply-To: <5034.1083952390@marajade.sandelman.ottawa.on.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 1) MM has its own issues coupled with the fact that it takes 6 messages to get anything done. What's next, a MM exchange for each DNS request. 2) If the DOS attacks are coming from machines that are "owned" MM has very similar properties to aggressive mode. 3) IKE for the purpose of off-path transport layer attacks is like using a jack hammer to drive a thin nail on a picture frame. 4) The proposed approach which is really equivalent to a pre-shared key that is hard coded into every IKE implementation opens us up for even more issues. I think the basic idea has merit, i.e. for certain applications the receiver must be in control of who it talks to. I am not sure IKE is the way to go for this. Bora > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Friday, May 07, 2004 10:53 AM > To: Bora Akyol > Cc: 'Joe Touch'; 'ipsec mailingList' > Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec > > > > >>>>> "Bora" == Bora Akyol writes: > Bora> Finally, as is widely discussed, IKEv1 is not the > most robust protocol > Bora> as far as responsiveness to DOS attacks. By > requiring these nodes to do > Bora> IKE, I think we would opening ourselves up for more > problems. > > IKE in aggressive mode has that property. > That's why smart people don't use that. > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 15:05:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13372 for ; Fri, 7 May 2004 15:05:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAW1-0003ek-QT; Fri, 07 May 2004 14:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAR3-0001rv-K0 for ipsec@optimus.ietf.org; Fri, 07 May 2004 14:51:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12031 for ; Fri, 7 May 2004 14:50:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMAR0-00069s-RN for ipsec@ietf.org; Fri, 07 May 2004 14:50:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAQ1-0005hr-00 for ipsec@ietf.org; Fri, 07 May 2004 14:49:58 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BMAP3-0005GL-00 for ipsec@ietf.org; Fri, 07 May 2004 14:48:57 -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 i47Ilp804924 for ; Fri, 7 May 2004 14:47:51 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47IjxkV004707 for ; Fri, 7 May 2004 14:45:59 -0400 (EDT) Received: from oetest.freeswan.org(205.150.200.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAAztaGlj; Fri, 7 May 04 14:45:57 -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 i47ImLP02359 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 May 2004 14:48:23 -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 i47InWE20193 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 May 2004 14:49:38 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47IhaRO007160 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 May 2004 14:43:36 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47IhaEI007157; Fri, 7 May 2004 14:43:36 -0400 To: "Bora Akyol" cc: "'Joe Touch'" , "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec In-Reply-To: Message from "Bora Akyol" of "Fri, 07 May 2004 11:29:42 PDT." <004c01c43461$442a6e40$050a0a0a@amer.cisco.com> References: <004c01c43461$442a6e40$050a0a0a@amer.cisco.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Fri, 07 May 2004 14:43:36 -0400 Message-ID: <7156.1083955416@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bora" == Bora Akyol writes: Bora> 1) MM has its own issues coupled with the fact that it takes 6 messages Bora> to get anything done. What's next, a MM exchange for each DNS Bora> request. a) we've done that, and it isn't as bad as you might think. There is a bootstrap issue if you are getting keys from DNS. b) MM for each new TCP connection that a router does isn't really that much of a deal. Routers do not talk TCP to many systems. Bora> 2) If the DOS attacks are coming from machines that are "owned" MM Bora> has very similar properties to aggressive mode. That's true. But, that's why IKE implementations needs to manage themselves very carefully. The point is to take all of our knowledge about how to defend against DDoS attacks and put it into one place so that we don't have to keep putting this into every protocol. Bora> 3) IKE for the purpose of off-path transport layer attacks is Bora> like using a jack hammer to drive a thin nail on a picture Bora> frame. Defending against such attacks will become more and more important. Bora> 4) The proposed approach which is really equivalent to a pre-shared key Bora> that is hard coded into every IKE implementation opens us up for even Bora> more issues. Yes, I agree. I'm not crazy about Joe's approach either. I know we can do better, because we have already done better. - -- ] ON HUMILITY: to err is human. To moo, bovine. | 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 iQCVAwUBQJvY14qHRg3pndX9AQFS3AP/TNYkL3V29314NflAYgddW8/RRscIhdaC b0UA0ZDlWOxMcOVjfHHoqXGCuOvbS/dcHTMVrMJOeBY1mtNY1Lai0pZy6ft6bU9q U+e5P652kw6TFif6jbk0PlEyel2Mc5cPrvmo+FmK6EPSF4+oRjj1KF9XIlp12rZH qaWR94fU3L4= =SIMz -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 15:14:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14660 for ; Fri, 7 May 2004 15:14:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAkn-0007g0-JQ for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 15:11:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47JBPwj029500 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 15:11:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAgt-00049f-SP for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 15:07:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13704 for ; Fri, 7 May 2004 15:07:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMAgq-0005fy-Tt for ipsec-web-archive@ietf.org; Fri, 07 May 2004 15:07:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAfp-0005Aq-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 15:06:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMAed-0004fD-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 15:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAW1-0003ek-QT; Fri, 07 May 2004 14:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAR3-0001rv-K0 for ipsec@optimus.ietf.org; Fri, 07 May 2004 14:51:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12031 for ; Fri, 7 May 2004 14:50:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMAR0-00069s-RN for ipsec@ietf.org; Fri, 07 May 2004 14:50:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAQ1-0005hr-00 for ipsec@ietf.org; Fri, 07 May 2004 14:49:58 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BMAP3-0005GL-00 for ipsec@ietf.org; Fri, 07 May 2004 14:48:57 -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 i47Ilp804924 for ; Fri, 7 May 2004 14:47:51 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47IjxkV004707 for ; Fri, 7 May 2004 14:45:59 -0400 (EDT) Received: from oetest.freeswan.org(205.150.200.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAAztaGlj; Fri, 7 May 04 14:45:57 -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 i47ImLP02359 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 May 2004 14:48:23 -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 i47InWE20193 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 May 2004 14:49:38 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47IhaRO007160 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 May 2004 14:43:36 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47IhaEI007157; Fri, 7 May 2004 14:43:36 -0400 To: "Bora Akyol" cc: "'Joe Touch'" , "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec In-Reply-To: Message from "Bora Akyol" of "Fri, 07 May 2004 11:29:42 PDT." <004c01c43461$442a6e40$050a0a0a@amer.cisco.com> References: <004c01c43461$442a6e40$050a0a0a@amer.cisco.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Fri, 07 May 2004 14:43:36 -0400 Message-ID: <7156.1083955416@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bora" == Bora Akyol writes: Bora> 1) MM has its own issues coupled with the fact that it takes 6 messages Bora> to get anything done. What's next, a MM exchange for each DNS Bora> request. a) we've done that, and it isn't as bad as you might think. There is a bootstrap issue if you are getting keys from DNS. b) MM for each new TCP connection that a router does isn't really that much of a deal. Routers do not talk TCP to many systems. Bora> 2) If the DOS attacks are coming from machines that are "owned" MM Bora> has very similar properties to aggressive mode. That's true. But, that's why IKE implementations needs to manage themselves very carefully. The point is to take all of our knowledge about how to defend against DDoS attacks and put it into one place so that we don't have to keep putting this into every protocol. Bora> 3) IKE for the purpose of off-path transport layer attacks is Bora> like using a jack hammer to drive a thin nail on a picture Bora> frame. Defending against such attacks will become more and more important. Bora> 4) The proposed approach which is really equivalent to a pre-shared key Bora> that is hard coded into every IKE implementation opens us up for even Bora> more issues. Yes, I agree. I'm not crazy about Joe's approach either. I know we can do better, because we have already done better. - -- ] ON HUMILITY: to err is human. To moo, bovine. | 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 iQCVAwUBQJvY14qHRg3pndX9AQFS3AP/TNYkL3V29314NflAYgddW8/RRscIhdaC b0UA0ZDlWOxMcOVjfHHoqXGCuOvbS/dcHTMVrMJOeBY1mtNY1Lai0pZy6ft6bU9q U+e5P652kw6TFif6jbk0PlEyel2Mc5cPrvmo+FmK6EPSF4+oRjj1KF9XIlp12rZH qaWR94fU3L4= =SIMz -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 15:38:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16052 for ; Fri, 7 May 2004 15:38:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMB6j-0007S3-VT; Fri, 07 May 2004 15:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMB3j-0006gG-GM for ipsec@optimus.ietf.org; Fri, 07 May 2004 15:30:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15797 for ; Fri, 7 May 2004 15:30:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMB3i-0000XX-4X for ipsec@ietf.org; Fri, 07 May 2004 15:30:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMB2i-000075-00 for ipsec@ietf.org; Fri, 07 May 2004 15:29:57 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BMB1p-00075D-00 for ipsec@ietf.org; Fri, 07 May 2004 15:29:01 -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 i47JSV7X016140; Fri, 7 May 2004 15:28:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Fri, 7 May 2004 15:26:46 -0400 To: Mark Duffy From: Stephen Kent Subject: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , mark, Sorry for the delay in replying, but a two week vacation creates a mountain of mail. I disagree with Karen's offer to reduce the ICMP checking requirement to a MAY. Let me explain my reasoning: We already require a receiver to check selector values for each packet received via an SA to ensure that the received traffic is consistent with the selector values used to negotiate the SA. At the highest level do this because we don't want to deliver traffic via an SA that is not consistent with the SA parameters. But, of course, the real reason is that we don't want to subject the hosts behind an IPsec implementation to attacks that would be feasible if we failed to do these checks on IP and transport layer headers. For ICMP traffic you suggest that we have fulfilled this sort of protection requirement if we match the traffic against the IP address selectors, verify that the protocol is ICMP, and that the type and code fields, are acceptable, relative to the specified selectors. However, if we look to the underlying reason for the checks we perform, we see that it is the payload of the ICMP packet, in the case of error messages, that has the data we really want to check. The argument is that the host will make decisions based on the header of the packet that purportedly triggered the error response, and so we ought to try to ensure that this header info is consistent with the SA via which it is received. If we don't then, for example, anyone with whom we have an active SA could send us an ICMP destination dead message that refers to any host/net with which we may communicate, and effect a pretty efficient DoS attack. So, the motivation for routing such traffic to a process in an IPsec implementation where this extended examination can be performed is motivated by this concern. One could choose to reject error messages using traffic selectors, to protect against such attacks, but that would diminish functionality considerably. Also note that this is not a new notion. Michael Richardson described this sort of processing in a memo some time ago. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 15:45:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16363 for ; Fri, 7 May 2004 15:45:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBDh-0001LY-Ky for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 15:41:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47JfHto005172 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 15:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBCa-000148-Bv for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 15:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16143 for ; Fri, 7 May 2004 15:40:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBCZ-0004NH-09 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 15:40:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBBg-0003xJ-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 15:39:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMBAs-0003Wi-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 15:38:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMB6j-0007S3-VT; Fri, 07 May 2004 15:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMB3j-0006gG-GM for ipsec@optimus.ietf.org; Fri, 07 May 2004 15:30:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15797 for ; Fri, 7 May 2004 15:30:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMB3i-0000XX-4X for ipsec@ietf.org; Fri, 07 May 2004 15:30:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMB2i-000075-00 for ipsec@ietf.org; Fri, 07 May 2004 15:29:57 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BMB1p-00075D-00 for ipsec@ietf.org; Fri, 07 May 2004 15:29:01 -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 i47JSV7X016140; Fri, 7 May 2004 15:28:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Fri, 7 May 2004 15:26:46 -0400 To: Mark Duffy From: Stephen Kent Subject: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 mark, Sorry for the delay in replying, but a two week vacation creates a mountain of mail. I disagree with Karen's offer to reduce the ICMP checking requirement to a MAY. Let me explain my reasoning: We already require a receiver to check selector values for each packet received via an SA to ensure that the received traffic is consistent with the selector values used to negotiate the SA. At the highest level do this because we don't want to deliver traffic via an SA that is not consistent with the SA parameters. But, of course, the real reason is that we don't want to subject the hosts behind an IPsec implementation to attacks that would be feasible if we failed to do these checks on IP and transport layer headers. For ICMP traffic you suggest that we have fulfilled this sort of protection requirement if we match the traffic against the IP address selectors, verify that the protocol is ICMP, and that the type and code fields, are acceptable, relative to the specified selectors. However, if we look to the underlying reason for the checks we perform, we see that it is the payload of the ICMP packet, in the case of error messages, that has the data we really want to check. The argument is that the host will make decisions based on the header of the packet that purportedly triggered the error response, and so we ought to try to ensure that this header info is consistent with the SA via which it is received. If we don't then, for example, anyone with whom we have an active SA could send us an ICMP destination dead message that refers to any host/net with which we may communicate, and effect a pretty efficient DoS attack. So, the motivation for routing such traffic to a process in an IPsec implementation where this extended examination can be performed is motivated by this concern. One could choose to reject error messages using traffic selectors, to protect against such attacks, but that would diminish functionality considerably. Also note that this is not a new notion. Michael Richardson described this sort of processing in a memo some time ago. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 16:22:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17918 for ; Fri, 7 May 2004 16:22:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBlQ-0003Pb-3U; Fri, 07 May 2004 16:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBeh-0001Rf-Hm for ipsec@optimus.ietf.org; Fri, 07 May 2004 16:09:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17495 for ; Fri, 7 May 2004 16:09:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBef-0001Gx-TP for ipsec@ietf.org; Fri, 07 May 2004 16:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBdp-0000pU-00 for ipsec@ietf.org; Fri, 07 May 2004 16:08:17 -0400 Received: from smtp802.mail.sc5.yahoo.com ([66.163.168.181]) by ietf-mx with smtp (Exim 4.12) id 1BMBcr-0000L3-00 for ipsec@ietf.org; Fri, 07 May 2004 16:07:17 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.59.221 with login) by smtp802.mail.sc5.yahoo.com with SMTP; 7 May 2004 20:07:15 -0000 Message-ID: <00df01c4346e$e5016fa0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Karen Seo" Cc: , "Mark Duffy" References: <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040426124209.020d5968@email> Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Date: Fri, 7 May 2004 13:07:16 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Karen, Just one clarification below.. > >I understand how, as you describe, this processing of icmp error > >messages might protect against certain DOS attacks. But it seems to > >me to be overzealous in your approach #2. > > > >In your approach #1 the icmp error message is being sent on an SA > >pair implied by the enclosed packet in the icmp payload. In that > >case I think it makes perfect sense for both IPsec devices to > >evaluate the SPD policy for that enclosed packet. > > > >But in #2 the icmp error message is being sent on an SA negotiated > >for protocol=icmp, type= and code=. It seems to me > >to be an impropriety for the IPsec implementation to check the > >enclosed packet. This would be checking that goes beyond the > >negotiated selectors -- AFAIK there is no other comparable thing > >done elsewhere in IPsec. > > Hmmm... ICMP messages can more directly cause problems > than regular data traffic. They could be used to > redirect traffic, change the PMTU, etc. So it seemed > to us that additional checking was warranted. > > > Should an IPsec implementation also check for invalid combinations > >of control bits in a tcp header? Or for packets with src addr == > >dest addr? These are also checks that could protect against attacks > >but they oughtn't IMO to be part of the *IPsec* processing. > > I think I understand what you're saying but verifying that > the packet enclosed in an ICMP message could have legitimately > come from an entity behind the local IPsec implementation seems > appropriate given the risks. I would like to at least leave > this check in as a note with a MAY. What do you think? Do > you want this check removed entirely? > > >P.S. Comments on the wording: > > - Regardless of what behavior is chosen, it would be better if the > >text does not describe a fast path and a slow path, and what is done > >in each. I don't think there is anything gained by including such > >implementation assumptions. > > OK. Will do. > > > - The phrase "to ensure that the enclosed packet is consistent > >with its source" could use some elaboration. > > Good point. Consistent --> the selector fields in the enclosed > packet match the selector fields for an existing SA. > You mean "the selector fields in the enclosed packet match the selector fields for an existing SA only if it is found". It is possible (and valid) to have an SA for protocol = icmp, type,code but not for the enclosed packet. -mohan > Karen > > _______________________________________________ > 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-admin@ietf.org Fri May 7 16:25:08 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18255 for ; Fri, 7 May 2004 16:25:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBnG-00043b-Q9; Fri, 07 May 2004 16:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBkW-00033R-Qr for ipsec@optimus.ietf.org; Fri, 07 May 2004 16:15:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17670 for ; Fri, 7 May 2004 16:15:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBkV-0003mT-1w for ipsec@ietf.org; Fri, 07 May 2004 16:15:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBjU-0003MZ-00 for ipsec@ietf.org; Fri, 07 May 2004 16:14:08 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BMBif-0002wi-00 for ipsec@ietf.org; Fri, 07 May 2004 16:13:17 -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 i47KC5811552 for ; Fri, 7 May 2004 16:12:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47KAjKQ015903 for ; Fri, 7 May 2004 16:10:45 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAgaOdF; Fri, 7 May 04 16:10:44 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47KAaJ16279; Fri, 7 May 2004 13:10:36 -0700 (PDT) Message-ID: <409BED3B.4080401@isi.edu> Date: Fri, 07 May 2004 13:10:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson CC: Bora Akyol , "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec References: <004c01c43461$442a6e40$050a0a0a@amer.cisco.com> <7156.1083955416@marajade.sandelman.ottawa.on.ca> In-Reply-To: <7156.1083955416@marajade.sandelman.ottawa.on.ca> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4488CF7210D41E310E68FB0C" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4488CF7210D41E310E68FB0C Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Richardson wrote: ... > Bora> 4) The proposed approach which is really equivalent to a pre-shared key > Bora> that is hard coded into every IKE implementation opens us up for even > Bora> more issues. > > Yes, I agree. I'm not crazy about Joe's approach either. > I know we can do better, because we have already done better. Can you be a little more specific about such alternatives? If there are alternatives that suffice for anonymous exchanges, please indicate what they are in addition to asserting their benefit (if it's equivalent, then it's not better ;-) - I'd prefer to use an existing approach, especially one I can cite. Thanks, Joe --------------enig4488CF7210D41E310E68FB0C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAm+07E5f5cImnZrsRAszAAKDKNL1crp/2H/V/AQRBXBT1WpPYPACg1wME TNQFWU8n4O09fkTaFGvC0aA= =lYb4 -----END PGP SIGNATURE----- --------------enig4488CF7210D41E310E68FB0C-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 7 16:36:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19141 for ; Fri, 7 May 2004 16:36:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMByi-0007g1-26 for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 16:29:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47KTqhX029510 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 16:29:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBtJ-0005us-Gj for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 16:24:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18047 for ; Fri, 7 May 2004 16:24:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBtH-0007mE-RO for ipsec-web-archive@ietf.org; Fri, 07 May 2004 16:24:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBs5-0007Er-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 16:23:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMBqv-0006PI-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 16:21:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBlQ-0003Pb-3U; Fri, 07 May 2004 16:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBeh-0001Rf-Hm for ipsec@optimus.ietf.org; Fri, 07 May 2004 16:09:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17495 for ; Fri, 7 May 2004 16:09:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBef-0001Gx-TP for ipsec@ietf.org; Fri, 07 May 2004 16:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBdp-0000pU-00 for ipsec@ietf.org; Fri, 07 May 2004 16:08:17 -0400 Received: from smtp802.mail.sc5.yahoo.com ([66.163.168.181]) by ietf-mx with smtp (Exim 4.12) id 1BMBcr-0000L3-00 for ipsec@ietf.org; Fri, 07 May 2004 16:07:17 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.59.221 with login) by smtp802.mail.sc5.yahoo.com with SMTP; 7 May 2004 20:07:15 -0000 Message-ID: <00df01c4346e$e5016fa0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Karen Seo" Cc: , "Mark Duffy" References: <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040426124209.020d5968@email> Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Date: Fri, 7 May 2004 13:07:16 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Karen, Just one clarification below.. > >I understand how, as you describe, this processing of icmp error > >messages might protect against certain DOS attacks. But it seems to > >me to be overzealous in your approach #2. > > > >In your approach #1 the icmp error message is being sent on an SA > >pair implied by the enclosed packet in the icmp payload. In that > >case I think it makes perfect sense for both IPsec devices to > >evaluate the SPD policy for that enclosed packet. > > > >But in #2 the icmp error message is being sent on an SA negotiated > >for protocol=icmp, type= and code=. It seems to me > >to be an impropriety for the IPsec implementation to check the > >enclosed packet. This would be checking that goes beyond the > >negotiated selectors -- AFAIK there is no other comparable thing > >done elsewhere in IPsec. > > Hmmm... ICMP messages can more directly cause problems > than regular data traffic. They could be used to > redirect traffic, change the PMTU, etc. So it seemed > to us that additional checking was warranted. > > > Should an IPsec implementation also check for invalid combinations > >of control bits in a tcp header? Or for packets with src addr == > >dest addr? These are also checks that could protect against attacks > >but they oughtn't IMO to be part of the *IPsec* processing. > > I think I understand what you're saying but verifying that > the packet enclosed in an ICMP message could have legitimately > come from an entity behind the local IPsec implementation seems > appropriate given the risks. I would like to at least leave > this check in as a note with a MAY. What do you think? Do > you want this check removed entirely? > > >P.S. Comments on the wording: > > - Regardless of what behavior is chosen, it would be better if the > >text does not describe a fast path and a slow path, and what is done > >in each. I don't think there is anything gained by including such > >implementation assumptions. > > OK. Will do. > > > - The phrase "to ensure that the enclosed packet is consistent > >with its source" could use some elaboration. > > Good point. Consistent --> the selector fields in the enclosed > packet match the selector fields for an existing SA. > You mean "the selector fields in the enclosed packet match the selector fields for an existing SA only if it is found". It is possible (and valid) to have an SA for protocol = icmp, type,code but not for the enclosed packet. -mohan > Karen > > _______________________________________________ > 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 exim@www1.ietf.org Fri May 7 16:37:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19224 for ; Fri, 7 May 2004 16:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBzK-0007lB-JJ for ipsec-archive@odin.ietf.org; Fri, 07 May 2004 16:30:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47KUUOT029824 for ipsec-archive@odin.ietf.org; Fri, 7 May 2004 16:30:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBvW-0006Zh-Ti for ipsec-web-archive@optimus.ietf.org; Fri, 07 May 2004 16:26:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18437 for ; Fri, 7 May 2004 16:26:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBvV-00010W-7x for ipsec-web-archive@ietf.org; Fri, 07 May 2004 16:26:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBuj-0000Y8-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 16:25:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMBtf-00001g-00 for ipsec-web-archive@ietf.org; Fri, 07 May 2004 16:24:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBnG-00043b-Q9; Fri, 07 May 2004 16:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBkW-00033R-Qr for ipsec@optimus.ietf.org; Fri, 07 May 2004 16:15:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17670 for ; Fri, 7 May 2004 16:15:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBkV-0003mT-1w for ipsec@ietf.org; Fri, 07 May 2004 16:15:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBjU-0003MZ-00 for ipsec@ietf.org; Fri, 07 May 2004 16:14:08 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BMBif-0002wi-00 for ipsec@ietf.org; Fri, 07 May 2004 16:13:17 -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 i47KC5811552 for ; Fri, 7 May 2004 16:12:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i47KAjKQ015903 for ; Fri, 7 May 2004 16:10:45 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAgaOdF; Fri, 7 May 04 16:10:44 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47KAaJ16279; Fri, 7 May 2004 13:10:36 -0700 (PDT) Message-ID: <409BED3B.4080401@isi.edu> Date: Fri, 07 May 2004 13:10:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson CC: Bora Akyol , "'ipsec mailingList'" Subject: Re: [Ipsec] new internet draftt - draft-touch-anonsec References: <004c01c43461$442a6e40$050a0a0a@amer.cisco.com> <7156.1083955416@marajade.sandelman.ottawa.on.ca> In-Reply-To: <7156.1083955416@marajade.sandelman.ottawa.on.ca> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4488CF7210D41E310E68FB0C" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4488CF7210D41E310E68FB0C Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Richardson wrote: ... > Bora> 4) The proposed approach which is really equivalent to a pre-shared key > Bora> that is hard coded into every IKE implementation opens us up for even > Bora> more issues. > > Yes, I agree. I'm not crazy about Joe's approach either. > I know we can do better, because we have already done better. Can you be a little more specific about such alternatives? If there are alternatives that suffice for anonymous exchanges, please indicate what they are in addition to asserting their benefit (if it's equivalent, then it's not better ;-) - I'd prefer to use an existing approach, especially one I can cite. Thanks, Joe --------------enig4488CF7210D41E310E68FB0C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAm+07E5f5cImnZrsRAszAAKDKNL1crp/2H/V/AQRBXBT1WpPYPACg1wME TNQFWU8n4O09fkTaFGvC0aA= =lYb4 -----END PGP SIGNATURE----- --------------enig4488CF7210D41E310E68FB0C-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun May 9 14:06:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13929 for ; Sun, 9 May 2004 14:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMsao-0008IA-E1; Sun, 09 May 2004 14:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMsWt-0007v3-2r for ipsec@optimus.ietf.org; Sun, 09 May 2004 13:55:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13384 for ; Sun, 9 May 2004 13:55:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMsWq-0000Ub-QQ for ipsec@ietf.org; Sun, 09 May 2004 13:55:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMsVu-0000Bo-00 for ipsec@ietf.org; Sun, 09 May 2004 13:54:59 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BMsV3-0007hJ-00 for ipsec@ietf.org; Sun, 09 May 2004 13:54:05 -0400 Received: from c9060876.virtua.com.br (c9060876.virtua.com.br [201.6.8.118]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i49Hqo806950 for ; Sun, 9 May 2004 13:52:51 -0400 (EDT) Date: Sun, 9 May 2004 13:52:51 -0400 (EDT) Received: from 223.249.136.224 by 201.6.8.118; Wed, 26 May 2004 03:50:17 +0600 Message-ID: From: "ipsec@portal.gw.tislabs.com" To: "ipsec@portal.gw.tislabs.com" MIME-Version: 1.0 Content-type: text X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] Gen^eric 6O% ch-ea-per soap Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , http://council.xc4xzzd.com/ti/#sway off http://sidelong.xc4xzzd.com/b.html#counteract Alvaro ----824349873000726424-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sun May 9 14:11:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14261 for ; Sun, 9 May 2004 14:11:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMsjZ-0001Nw-Sd for ipsec-archive@odin.ietf.org; Sun, 09 May 2004 14:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i49I95bj005318 for ipsec-archive@odin.ietf.org; Sun, 9 May 2004 14:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMsiU-0001B5-TT for ipsec-web-archive@optimus.ietf.org; Sun, 09 May 2004 14:07:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14041 for ; Sun, 9 May 2004 14:07:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMsiS-0004Cl-J4 for ipsec-web-archive@ietf.org; Sun, 09 May 2004 14:07:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMshZ-0003uz-00 for ipsec-web-archive@ietf.org; Sun, 09 May 2004 14:07:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMsgj-0003cX-00 for ipsec-web-archive@ietf.org; Sun, 09 May 2004 14:06:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMsao-0008IA-E1; Sun, 09 May 2004 14:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMsWt-0007v3-2r for ipsec@optimus.ietf.org; Sun, 09 May 2004 13:55:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13384 for ; Sun, 9 May 2004 13:55:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMsWq-0000Ub-QQ for ipsec@ietf.org; Sun, 09 May 2004 13:55:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMsVu-0000Bo-00 for ipsec@ietf.org; Sun, 09 May 2004 13:54:59 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BMsV3-0007hJ-00 for ipsec@ietf.org; Sun, 09 May 2004 13:54:05 -0400 Received: from c9060876.virtua.com.br (c9060876.virtua.com.br [201.6.8.118]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i49Hqo806950 for ; Sun, 9 May 2004 13:52:51 -0400 (EDT) Date: Sun, 9 May 2004 13:52:51 -0400 (EDT) Received: from 223.249.136.224 by 201.6.8.118; Wed, 26 May 2004 03:50:17 +0600 Message-ID: From: "ipsec@portal.gw.tislabs.com" To: "ipsec@portal.gw.tislabs.com" MIME-Version: 1.0 Content-type: text Subject: [Ipsec] Gen^eric 6O% ch-ea-per soap Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 http://council.xc4xzzd.com/ti/#sway off http://sidelong.xc4xzzd.com/b.html#counteract Alvaro ----824349873000726424-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 17:29:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07448 for ; Mon, 10 May 2004 17:29:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNID0-0005jw-E0; Mon, 10 May 2004 17:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNHuV-00075R-1B for ipsec@optimus.ietf.org; Mon, 10 May 2004 17:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04078 for ; Mon, 10 May 2004 17:01:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNHuS-0003uk-Tf for ipsec@ietf.org; Mon, 10 May 2004 17:02:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNHsc-0003Hf-00 for ipsec@ietf.org; Mon, 10 May 2004 17:00:06 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNHqZ-0002K1-00 for ipsec@ietf.org; Mon, 10 May 2004 16:57:59 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 10 May 2004 13:57:27 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 May 2004 13:57:29 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 13:57:10 -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: Mon, 10 May 2004 13:57:27 -0700 Message-ID: Thread-Topic: Updating IKEv2 thread-index: AcQx91fAZY1ZGT2/SGStXFpbiWel3QE2erLA From: "Charlie Kaufman" To: "Barbara Fraser" Cc: , , , "Theodore Y. Ts'o" X-OriginalArrivalTime: 10 May 2004 20:57:10.0616 (UTC) FILETIME=[5CCC1580:01C436D1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] RE: Updating IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sorry for the slow response; I posted a list of issues I don't know how to resolve yesterday, but I think my message is awaiting moderator approval in the IPsec queue. --Charlie -----Original Message----- From: Barbara Fraser [mailto:byfraser@cisco.com]=20 Sent: Tuesday, May 04, 2004 9:46 AM To: Charlie Kaufman Cc: Barbara Fraser; kivinen@iki.fi; ipsec@ietf.org; angelos@cs.columbia.edu; Theodore Y. Ts'o Subject: Updating IKEv2 Hi Charlie, The issue tracker contains the issues raised during the IETF last call.=20 Please go ahead and update the document to address these remaining=20 issues. If you have any questions about any of them, please post to the=20 list. We'd like to have a final version as soon as reasonably possible. thanks a bunch, Barb and Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 10 17:55:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09016 for ; Mon, 10 May 2004 17:55:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIaP-0003fT-81 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 17:45:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ALjKLF014091 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 17:45:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNINb-0000S5-90 for ipsec-web-archive@optimus.ietf.org; Mon, 10 May 2004 17:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07879 for ; Mon, 10 May 2004 17:32:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNINY-00076f-P5 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 17:32:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIMA-0006YB-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 17:30:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNIKO-00060E-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 17:28:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNID0-0005jw-E0; Mon, 10 May 2004 17:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNHuV-00075R-1B for ipsec@optimus.ietf.org; Mon, 10 May 2004 17:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04078 for ; Mon, 10 May 2004 17:01:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNHuS-0003uk-Tf for ipsec@ietf.org; Mon, 10 May 2004 17:02:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNHsc-0003Hf-00 for ipsec@ietf.org; Mon, 10 May 2004 17:00:06 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNHqZ-0002K1-00 for ipsec@ietf.org; Mon, 10 May 2004 16:57:59 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 10 May 2004 13:57:27 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 May 2004 13:57:29 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 13:57:10 -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: Mon, 10 May 2004 13:57:27 -0700 Message-ID: Thread-Topic: Updating IKEv2 thread-index: AcQx91fAZY1ZGT2/SGStXFpbiWel3QE2erLA From: "Charlie Kaufman" To: "Barbara Fraser" Cc: , , , "Theodore Y. Ts'o" X-OriginalArrivalTime: 10 May 2004 20:57:10.0616 (UTC) FILETIME=[5CCC1580:01C436D1] Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] RE: Updating IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sorry for the slow response; I posted a list of issues I don't know how to resolve yesterday, but I think my message is awaiting moderator approval in the IPsec queue. --Charlie -----Original Message----- From: Barbara Fraser [mailto:byfraser@cisco.com]=20 Sent: Tuesday, May 04, 2004 9:46 AM To: Charlie Kaufman Cc: Barbara Fraser; kivinen@iki.fi; ipsec@ietf.org; angelos@cs.columbia.edu; Theodore Y. Ts'o Subject: Updating IKEv2 Hi Charlie, The issue tracker contains the issues raised during the IETF last call.=20 Please go ahead and update the document to address these remaining=20 issues. If you have any questions about any of them, please post to the=20 list. We'd like to have a final version as soon as reasonably possible. thanks a bunch, Barb and Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 18:33:32 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12700 for ; Mon, 10 May 2004 18:33:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJAv-0002pi-KC; Mon, 10 May 2004 18:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIzR-0005KV-C1 for ipsec@optimus.ietf.org; Mon, 10 May 2004 18:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10943 for ; Mon, 10 May 2004 18:11:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNIzO-0005bH-J2 for ipsec@ietf.org; Mon, 10 May 2004 18:11:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIyZ-0005Fs-00 for ipsec@ietf.org; Mon, 10 May 2004 18:10:19 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BNIxu-0004rF-00 for ipsec@ietf.org; Mon, 10 May 2004 18:09:38 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.134]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41LPK3; Mon, 10 May 2004 18:09:08 -0400 Message-Id: <5.2.0.9.0.20040510180120.02926b80@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 May 2004 18:08:31 -0400 To: Stephen Kent From: Mark Duffy Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi Steve, I do not question that the checks on the icmp payload packet would provide an added measure of security -- I agree that they would. However I would like to understand where we are drawing the line about what an "IPsec implementation" should check. Should it check for invalid combinations of control bits in a tcp header (e.g. SYN and FIN)? Or for packets with src addr == dest addr? Etc. Is there something fundamentally different about checking the payload of an ICMP packet that is sent on an SA negotiated for protocol=icmp than there is about doing the other checks I mentioned? --Mark At 03:26 PM 5/7/2004 -0400, Stephen Kent wrote: >mark, > >Sorry for the delay in replying, but a two week vacation creates a >mountain of mail. I disagree with Karen's offer to reduce the ICMP >checking requirement to a MAY. Let me explain my reasoning: > >We already require a receiver to check selector values for each packet >received via an SA to ensure that the received traffic is consistent with >the selector values used to negotiate the SA. At the highest level do >this because we don't want to deliver traffic via an SA that is not >consistent with the SA parameters. But, of course, the real reason is that >we don't want to subject the hosts behind an IPsec implementation to >attacks that would be feasible if we failed to do these checks on IP and >transport layer headers. > >For ICMP traffic you suggest that we have fulfilled this sort of >protection requirement if we match the traffic against the IP address >selectors, verify that the protocol is ICMP, and that the type and code >fields, are acceptable, relative to the specified selectors. However, if >we look to the underlying reason for the checks we perform, we see that it >is the payload of the ICMP packet, in the case of error messages, that has >the data we really want to check. The argument is that the host will make >decisions based on the header of the packet that purportedly triggered the >error response, and so we ought to try to ensure that this header info is >consistent with the SA via which it is received. If we don't then, for >example, anyone with whom we have an active SA could send us an ICMP >destination dead message that refers to any host/net with which we may >communicate, and effect a pretty efficient DoS attack. So, the motivation >for routing such traffic to a process in an IPsec implementation where >this extended examination can be performed is motivated by this concern. >One could choose to reject error messages using traffic selectors, to >protect against such attacks, but that would diminish functionality >considerably. > >Also note that this is not a new notion. Michael Richardson described >this sort of processing in a memo some time ago. > >Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 10 18:55:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14510 for ; Mon, 10 May 2004 18:55:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJSb-0007Eo-OK for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 18:41:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AMfLhl027816 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 18:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJMe-0005RQ-GJ for ipsec-web-archive@optimus.ietf.org; Mon, 10 May 2004 18:35:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12869 for ; Mon, 10 May 2004 18:35:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNJMb-0006Dj-GM for ipsec-web-archive@ietf.org; Mon, 10 May 2004 18:35:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNJLa-0005qe-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 18:34:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNJKa-0005Sk-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 18:33:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJAv-0002pi-KC; Mon, 10 May 2004 18:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIzR-0005KV-C1 for ipsec@optimus.ietf.org; Mon, 10 May 2004 18:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10943 for ; Mon, 10 May 2004 18:11:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNIzO-0005bH-J2 for ipsec@ietf.org; Mon, 10 May 2004 18:11:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIyZ-0005Fs-00 for ipsec@ietf.org; Mon, 10 May 2004 18:10:19 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BNIxu-0004rF-00 for ipsec@ietf.org; Mon, 10 May 2004 18:09:38 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.134]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41LPK3; Mon, 10 May 2004 18:09:08 -0400 Message-Id: <5.2.0.9.0.20040510180120.02926b80@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 May 2004 18:08:31 -0400 To: Stephen Kent From: Mark Duffy Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Steve, I do not question that the checks on the icmp payload packet would provide an added measure of security -- I agree that they would. However I would like to understand where we are drawing the line about what an "IPsec implementation" should check. Should it check for invalid combinations of control bits in a tcp header (e.g. SYN and FIN)? Or for packets with src addr == dest addr? Etc. Is there something fundamentally different about checking the payload of an ICMP packet that is sent on an SA negotiated for protocol=icmp than there is about doing the other checks I mentioned? --Mark At 03:26 PM 5/7/2004 -0400, Stephen Kent wrote: >mark, > >Sorry for the delay in replying, but a two week vacation creates a >mountain of mail. I disagree with Karen's offer to reduce the ICMP >checking requirement to a MAY. Let me explain my reasoning: > >We already require a receiver to check selector values for each packet >received via an SA to ensure that the received traffic is consistent with >the selector values used to negotiate the SA. At the highest level do >this because we don't want to deliver traffic via an SA that is not >consistent with the SA parameters. But, of course, the real reason is that >we don't want to subject the hosts behind an IPsec implementation to >attacks that would be feasible if we failed to do these checks on IP and >transport layer headers. > >For ICMP traffic you suggest that we have fulfilled this sort of >protection requirement if we match the traffic against the IP address >selectors, verify that the protocol is ICMP, and that the type and code >fields, are acceptable, relative to the specified selectors. However, if >we look to the underlying reason for the checks we perform, we see that it >is the payload of the ICMP packet, in the case of error messages, that has >the data we really want to check. The argument is that the host will make >decisions based on the header of the packet that purportedly triggered the >error response, and so we ought to try to ensure that this header info is >consistent with the SA via which it is received. If we don't then, for >example, anyone with whom we have an active SA could send us an ICMP >destination dead message that refers to any host/net with which we may >communicate, and effect a pretty efficient DoS attack. So, the motivation >for routing such traffic to a process in an IPsec implementation where >this extended examination can be performed is motivated by this concern. >One could choose to reject error messages using traffic selectors, to >protect against such attacks, but that would diminish functionality >considerably. > >Also note that this is not a new notion. Michael Richardson described >this sort of processing in a memo some time ago. > >Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 19:23:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16008 for ; Mon, 10 May 2004 19:23:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJuQ-00052p-59; Mon, 10 May 2004 19:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJq4-0003TE-LZ for ipsec@optimus.ietf.org; Mon, 10 May 2004 19:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15144 for ; Mon, 10 May 2004 19:05:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNJq1-0001ZX-21 for ipsec@ietf.org; Mon, 10 May 2004 19:05:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNJp8-0001Bq-00 for ipsec@ietf.org; Mon, 10 May 2004 19:04:39 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNJo7-0000h4-00 for ipsec@ietf.org; Mon, 10 May 2004 19:03:35 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 10 May 2004 16:02:12 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 May 2004 16:02:13 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 16:01:50 -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: Mon, 10 May 2004 16:02:13 -0700 Message-ID: Thread-Topic: Remaining issues for IKEv2 thread-index: AcQ2UdVn+tiAYBwrS4mj9Ek/xQnSFQAkNIFQ From: "Charlie Kaufman" To: X-OriginalArrivalTime: 10 May 2004 23:01:50.0476 (UTC) FILETIME=[C72424C0:01C436E2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] FW: Remaining issues for IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Resend... this apparently got lost -----Original Message----- From: Charlie Kaufman=20 Sent: Sunday, May 09, 2004 10:44 PM To: ipsec@ietf.org Subject: Remaining issues for IKEv2 There are currently 14 open issues in the issue tracker database re: IKEv2. I believe four others have been raised on the list but are not in the issue tracker. Of the 18, six (#101, #102, #104, #105, #106, and #107) are requested changes to the IANA initial database I-D, six (#94, #97, #99, #100, #103 and one unnumbered) contained proposed text or were specific enough that I have updated the IKEv2 I-D, three (#95 and two unnumbered) I believe should be rejected, and for the remaining three (#96, #97, and one unnumbered) I need guidance. Possible sources of controversy: Done: The unnumbered one that I've updated is from Ted Ts'o's message of 4/6/04 proposing that the phrase "to pass an account name or" be removed from the definition of ID_KEY_ID. Not done, recommend reject: #95 involved having an optional variation of the EAP authentication exchange that is two messages shorter. There was limited discussion on the list, but most of that was negative. Proposal by Yoav Nir 4/14/04 to support periodic reauthentication. This proposal came after the end of IETF Last Call and would add complexity to the protocol. Recommend this be considered as an optional extension if anyone is motivated enough to pursue it. Apparent inconsistency pointed out by Peter Brubmair on 4/30/04 that Appendix B talks about five Diffie-Hellman groups but only defines four. The fifth was removed in revision -09 because it is defined in [ADDGROUP]. The wording could be clearer, but it wasn't obvious how (to me), and I don't believe it is technically wrong. Recommend no change. Need Guidance: Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change the computation of the AUTH payload. This is yet another "gilding the lily" crypto modification. I am confident it adds no cryptographic strength to the protocol and it breaks compatibility with anyone who has implemented this stuff already, but it adds only trivial complexity to the protocol and a trivial computational overhead. In the past, it's been easier to just accept these proposals than to argue. One last time?? Handling of OPAQUE. (#96 and #98). An agreement has been reached on the handling of fragments in RFC2401bis, but it's not obvious how to reflect that agreement in IKEv2. My (perhaps oversimplified) understanding is as follows: The problem arises because IPsec SAs can be limited to specific ports of TCP and UDP and a single pair of endpoints can have different SAs for different classes of traffic. If the sending endpoint needs to forward an IP fragment other than the first, it may not be able to determine what port the reassembled packet will contain and therefore may not know which SA to forward it on (or whether to forward it at all). In some cases, the sending endpoint will know to which port the fragment is destined (either because it did the fragmentation or because it has already forwarded the first fragment and kept state to recognize subsequent ones). In that case, it would be most natural to send the fragment on the "correct" SA. In some cases, the sending endpoint will not know to which port the fragment is destined. In that case, it must either discard the fragment, guess the correct SA, or have an SA designated as carrying non-initial fragments. The receiving endpoint faces a corresponding decision. When it receives a non-initial fragment on an SA willing to accept traffic for some ports but not others, it can either forward the packet or discard it. It may have kept enough state to know whether this fragment is destined for an allowed port or it may not. The question for IKEv2 is: what indication (if any) of fragment handling policies should be included in the IKEv2 negotiation. The choices are: 1) None. If the sending endpoint forwards a fragment on an SA unacceptable to the receiving endpoint, the receiving endpoint discards it and the connection with fragmentation likely fails. This behavior can be avoided either by having the endpoints use the same scheme for directing fragments or by having the receiving endpoint generously accept fragments on any SA that accepts any ports of the protocol. 2) Explicitly negotiate a fragment carrying SA. Add some syntax to traffic selectors that allows an SA to negotiate the ability to send and receive fragments with unknown port (OPAQUE). This might be supplemented with some ability to negotiate whether non-initial fragments can alternatively be sent on the same SA as the initial fragment. One proposed encoding is a (previously invalid) port range of 65535 - 0 as indicating acceptance of non-initial fragments. 3) I'm sure there are other possibilities as well. My recommendation is (1), with a short explanation of the situation and a pointer to RFC2401bis, but I'm open to other options. --Charlie _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 10 19:49:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16994 for ; Mon, 10 May 2004 19:49:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNKRO-0003PK-8M for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 19:44:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ANiANJ013093 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 19:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNKLy-0002Qw-Ux for ipsec-web-archive@optimus.ietf.org; Mon, 10 May 2004 19:38:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16613 for ; Mon, 10 May 2004 19:38:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNKLx-0005Ct-7o for ipsec-web-archive@ietf.org; Mon, 10 May 2004 19:38:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNKL4-0004oj-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 19:37:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BNKJX-00045q-01 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 19:36:03 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BNK77-0005ef-0d for ipsec-web-archive@ietf.org; Mon, 10 May 2004 19:23:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJuQ-00052p-59; Mon, 10 May 2004 19:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJq4-0003TE-LZ for ipsec@optimus.ietf.org; Mon, 10 May 2004 19:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15144 for ; Mon, 10 May 2004 19:05:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNJq1-0001ZX-21 for ipsec@ietf.org; Mon, 10 May 2004 19:05:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNJp8-0001Bq-00 for ipsec@ietf.org; Mon, 10 May 2004 19:04:39 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNJo7-0000h4-00 for ipsec@ietf.org; Mon, 10 May 2004 19:03:35 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 10 May 2004 16:02:12 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 May 2004 16:02:13 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 16:01:50 -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: Mon, 10 May 2004 16:02:13 -0700 Message-ID: Thread-Topic: Remaining issues for IKEv2 thread-index: AcQ2UdVn+tiAYBwrS4mj9Ek/xQnSFQAkNIFQ From: "Charlie Kaufman" To: X-OriginalArrivalTime: 10 May 2004 23:01:50.0476 (UTC) FILETIME=[C72424C0:01C436E2] Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] FW: Remaining issues for IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Resend... this apparently got lost -----Original Message----- From: Charlie Kaufman=20 Sent: Sunday, May 09, 2004 10:44 PM To: ipsec@ietf.org Subject: Remaining issues for IKEv2 There are currently 14 open issues in the issue tracker database re: IKEv2. I believe four others have been raised on the list but are not in the issue tracker. Of the 18, six (#101, #102, #104, #105, #106, and #107) are requested changes to the IANA initial database I-D, six (#94, #97, #99, #100, #103 and one unnumbered) contained proposed text or were specific enough that I have updated the IKEv2 I-D, three (#95 and two unnumbered) I believe should be rejected, and for the remaining three (#96, #97, and one unnumbered) I need guidance. Possible sources of controversy: Done: The unnumbered one that I've updated is from Ted Ts'o's message of 4/6/04 proposing that the phrase "to pass an account name or" be removed from the definition of ID_KEY_ID. Not done, recommend reject: #95 involved having an optional variation of the EAP authentication exchange that is two messages shorter. There was limited discussion on the list, but most of that was negative. Proposal by Yoav Nir 4/14/04 to support periodic reauthentication. This proposal came after the end of IETF Last Call and would add complexity to the protocol. Recommend this be considered as an optional extension if anyone is motivated enough to pursue it. Apparent inconsistency pointed out by Peter Brubmair on 4/30/04 that Appendix B talks about five Diffie-Hellman groups but only defines four. The fifth was removed in revision -09 because it is defined in [ADDGROUP]. The wording could be clearer, but it wasn't obvious how (to me), and I don't believe it is technically wrong. Recommend no change. Need Guidance: Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change the computation of the AUTH payload. This is yet another "gilding the lily" crypto modification. I am confident it adds no cryptographic strength to the protocol and it breaks compatibility with anyone who has implemented this stuff already, but it adds only trivial complexity to the protocol and a trivial computational overhead. In the past, it's been easier to just accept these proposals than to argue. One last time?? Handling of OPAQUE. (#96 and #98). An agreement has been reached on the handling of fragments in RFC2401bis, but it's not obvious how to reflect that agreement in IKEv2. My (perhaps oversimplified) understanding is as follows: The problem arises because IPsec SAs can be limited to specific ports of TCP and UDP and a single pair of endpoints can have different SAs for different classes of traffic. If the sending endpoint needs to forward an IP fragment other than the first, it may not be able to determine what port the reassembled packet will contain and therefore may not know which SA to forward it on (or whether to forward it at all). In some cases, the sending endpoint will know to which port the fragment is destined (either because it did the fragmentation or because it has already forwarded the first fragment and kept state to recognize subsequent ones). In that case, it would be most natural to send the fragment on the "correct" SA. In some cases, the sending endpoint will not know to which port the fragment is destined. In that case, it must either discard the fragment, guess the correct SA, or have an SA designated as carrying non-initial fragments. The receiving endpoint faces a corresponding decision. When it receives a non-initial fragment on an SA willing to accept traffic for some ports but not others, it can either forward the packet or discard it. It may have kept enough state to know whether this fragment is destined for an allowed port or it may not. The question for IKEv2 is: what indication (if any) of fragment handling policies should be included in the IKEv2 negotiation. The choices are: 1) None. If the sending endpoint forwards a fragment on an SA unacceptable to the receiving endpoint, the receiving endpoint discards it and the connection with fragmentation likely fails. This behavior can be avoided either by having the endpoints use the same scheme for directing fragments or by having the receiving endpoint generously accept fragments on any SA that accepts any ports of the protocol. 2) Explicitly negotiate a fragment carrying SA. Add some syntax to traffic selectors that allows an SA to negotiate the ability to send and receive fragments with unknown port (OPAQUE). This might be supplemented with some ability to negotiate whether non-initial fragments can alternatively be sent on the same SA as the initial fragment. One proposed encoding is a (previously invalid) port range of 65535 - 0 as indicating acceptance of non-initial fragments. 3) I'm sure there are other possibilities as well. My recommendation is (1), with a short explanation of the situation and a pointer to RFC2401bis, but I'm open to other options. --Charlie _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 21:05:00 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20233 for ; Mon, 10 May 2004 21:05:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLX0-0001GA-Ni; Mon, 10 May 2004 20:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLTO-0000QV-Oj for ipsec@optimus.ietf.org; Mon, 10 May 2004 20:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19577 for ; Mon, 10 May 2004 20:50:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNLTM-000674-Au for ipsec@ietf.org; Mon, 10 May 2004 20:50:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLSP-0005mz-00 for ipsec@ietf.org; Mon, 10 May 2004 20:49:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNLRq-0005TB-00 for ipsec@ietf.org; Mon, 10 May 2004 20:48:42 -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 i4B0mYbd032843; Mon, 10 May 2004 17:48:35 -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: Mon, 10 May 2004 17:48:38 -0700 To: "Charlie Kaufman" , From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 4:02 PM -0700 5/10/04, Charlie Kaufman wrote: >Not done, recommend reject: > >#95 involved having an optional variation of the EAP authentication >exchange that is two messages shorter. There was limited discussion on >the list, but most of that was negative. > >Proposal by Yoav Nir 4/14/04 to support periodic reauthentication. This >proposal came after the end of IETF Last Call and would add complexity >to the protocol. Recommend this be considered as an optional extension >if anyone is motivated enough to pursue it. > >Apparent inconsistency pointed out by Peter Brubmair on 4/30/04 that >Appendix B talks about five Diffie-Hellman groups but only defines four. >The fifth was removed in revision -09 because it is defined in >[ADDGROUP]. The wording could be clearer, but it wasn't obvious how (to >me), and I don't believe it is technically wrong. Recommend no change. Agree with you that we should not do any of those three. The first two are obvious candidates for extensions if people really care about them. >Need Guidance: > >Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change >the computation of the AUTH payload. This is yet another "gilding the >lily" crypto modification. I am confident it adds no cryptographic >strength to the protocol and it breaks compatibility with anyone who has >implemented this stuff already, but it adds only trivial complexity to >the protocol and a trivial computational overhead. In the past, it's >been easier to just accept these proposals than to argue. One last >time?? Yes, just accept the change from the CFRG. No one has even gotten close to deploying, so backwards compatibility is a complete non-issue. >The question for IKEv2 is: what indication (if any) of fragment handling >policies should be included in the IKEv2 negotiation. The choices are: > >1) None. If the sending endpoint forwards a fragment on an SA >unacceptable to the receiving endpoint, the receiving endpoint discards >it and the connection with fragmentation likely fails. This behavior can >be avoided either by having the endpoints use the same scheme for >directing fragments or by having the receiving endpoint generously >accept fragments on any SA that accepts any ports of the protocol. > >2) Explicitly negotiate a fragment carrying SA. Add some syntax to >traffic selectors that allows an SA to negotiate the ability to send and >receive fragments with unknown port (OPAQUE). This might be supplemented >with some ability to negotiate whether non-initial fragments can >alternatively be sent on the same SA as the initial fragment. One >proposed encoding is a (previously invalid) port range of 65535 - 0 as >indicating acceptance of non-initial fragments. > >3) I'm sure there are other possibilities as well. > >My recommendation is (1), with a short explanation of the situation and >a pointer to RFC2401bis, but I'm open to other options. Agree with you on (1). It is way too late in the process for us to think about the security and design issues for (2), although someone can add an extension for it later if people really care about it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 10 21:19:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20733 for ; Mon, 10 May 2004 21:19:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLnj-0004yD-Ip for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 21:11:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B1BJHi019100 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 21:11:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLj2-0003oO-8z for ipsec-web-archive@optimus.ietf.org; Mon, 10 May 2004 21:06:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20338 for ; Mon, 10 May 2004 21:06:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNLiz-0003rs-Qy for ipsec-web-archive@ietf.org; Mon, 10 May 2004 21:06:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLhy-0003WX-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 21:05:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNLh9-0003BQ-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 21:04:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLX0-0001GA-Ni; Mon, 10 May 2004 20:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNLTO-0000QV-Oj for ipsec@optimus.ietf.org; Mon, 10 May 2004 20:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19577 for ; Mon, 10 May 2004 20:50:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNLTM-000674-Au for ipsec@ietf.org; Mon, 10 May 2004 20:50:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNLSP-0005mz-00 for ipsec@ietf.org; Mon, 10 May 2004 20:49:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNLRq-0005TB-00 for ipsec@ietf.org; Mon, 10 May 2004 20:48:42 -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 i4B0mYbd032843; Mon, 10 May 2004 17:48:35 -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: Mon, 10 May 2004 17:48:38 -0700 To: "Charlie Kaufman" , From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 4:02 PM -0700 5/10/04, Charlie Kaufman wrote: >Not done, recommend reject: > >#95 involved having an optional variation of the EAP authentication >exchange that is two messages shorter. There was limited discussion on >the list, but most of that was negative. > >Proposal by Yoav Nir 4/14/04 to support periodic reauthentication. This >proposal came after the end of IETF Last Call and would add complexity >to the protocol. Recommend this be considered as an optional extension >if anyone is motivated enough to pursue it. > >Apparent inconsistency pointed out by Peter Brubmair on 4/30/04 that >Appendix B talks about five Diffie-Hellman groups but only defines four. >The fifth was removed in revision -09 because it is defined in >[ADDGROUP]. The wording could be clearer, but it wasn't obvious how (to >me), and I don't believe it is technically wrong. Recommend no change. Agree with you that we should not do any of those three. The first two are obvious candidates for extensions if people really care about them. >Need Guidance: > >Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change >the computation of the AUTH payload. This is yet another "gilding the >lily" crypto modification. I am confident it adds no cryptographic >strength to the protocol and it breaks compatibility with anyone who has >implemented this stuff already, but it adds only trivial complexity to >the protocol and a trivial computational overhead. In the past, it's >been easier to just accept these proposals than to argue. One last >time?? Yes, just accept the change from the CFRG. No one has even gotten close to deploying, so backwards compatibility is a complete non-issue. >The question for IKEv2 is: what indication (if any) of fragment handling >policies should be included in the IKEv2 negotiation. The choices are: > >1) None. If the sending endpoint forwards a fragment on an SA >unacceptable to the receiving endpoint, the receiving endpoint discards >it and the connection with fragmentation likely fails. This behavior can >be avoided either by having the endpoints use the same scheme for >directing fragments or by having the receiving endpoint generously >accept fragments on any SA that accepts any ports of the protocol. > >2) Explicitly negotiate a fragment carrying SA. Add some syntax to >traffic selectors that allows an SA to negotiate the ability to send and >receive fragments with unknown port (OPAQUE). This might be supplemented >with some ability to negotiate whether non-initial fragments can >alternatively be sent on the same SA as the initial fragment. One >proposed encoding is a (previously invalid) port range of 65535 - 0 as >indicating acceptance of non-initial fragments. > >3) I'm sure there are other possibilities as well. > >My recommendation is (1), with a short explanation of the situation and >a pointer to RFC2401bis, but I'm open to other options. Agree with you on (1). It is way too late in the process for us to think about the security and design issues for (2), although someone can add an extension for it later if people really care about it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 21:54:14 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22026 for ; Mon, 10 May 2004 21:54:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMKM-0002w4-GQ; Mon, 10 May 2004 21:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMEt-0001jQ-P0 for ipsec@optimus.ietf.org; Mon, 10 May 2004 21:39:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21430 for ; Mon, 10 May 2004 21:39:20 -0400 (EDT) From: uri@lucent.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNMEq-0006wQ-Sm for ipsec@ietf.org; Mon, 10 May 2004 21:39:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMDq-0006cC-00 for ipsec@ietf.org; Mon, 10 May 2004 21:38:18 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BNMDF-0006Ip-00 for ipsec@ietf.org; Mon, 10 May 2004 21:37:41 -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 i4B1aV811721 for ; Mon, 10 May 2004 21:36:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4B1Yr6o021504 for ; Mon, 10 May 2004 21:34:53 -0400 (EDT) Received: from apointe-a-pitre-101-2-1-108.w217-128.abo.wanadoo.fr(217.128.117.108) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXtai0P; Mon, 10 May 04 21:34:14 -0400 Date: Wed, 12 May 2004 21:36:08 -0400 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------luhfwzolaiywfzilheva" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=AWL,DATE_IN_FUTURE_24_48, HTML_30_40,HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING, LINES_OF_YELLING_2,MIME_HTML_ONLY,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Incoming message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------luhfwzolaiywfzilheva Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Your file is attached.


----------luhfwzolaiywfzilheva Content-Type: text/html; name="Details.hta.htm" Content-Disposition: attachment; filename="Details.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: Details.hta
Virus name: W32/Bagle.z@MM!vbs

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

----------luhfwzolaiywfzilheva-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 10 22:12:23 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23604 for ; Mon, 10 May 2004 22:12:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMcg-0006E1-G5 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 22:03:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B23wmT023930 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 22:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMUR-0004ur-AS for ipsec-web-archive@optimus.ietf.org; Mon, 10 May 2004 21:55:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22078 for ; Mon, 10 May 2004 21:55:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNMUO-0004XF-Db for ipsec-web-archive@ietf.org; Mon, 10 May 2004 21:55:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMTU-0004D3-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 21:54:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNMSn-0003sN-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 21:53:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMKM-0002w4-GQ; Mon, 10 May 2004 21:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNMEt-0001jQ-P0 for ipsec@optimus.ietf.org; Mon, 10 May 2004 21:39:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21430 for ; Mon, 10 May 2004 21:39:20 -0400 (EDT) From: uri@lucent.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNMEq-0006wQ-Sm for ipsec@ietf.org; Mon, 10 May 2004 21:39:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNMDq-0006cC-00 for ipsec@ietf.org; Mon, 10 May 2004 21:38:18 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BNMDF-0006Ip-00 for ipsec@ietf.org; Mon, 10 May 2004 21:37:41 -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 i4B1aV811721 for ; Mon, 10 May 2004 21:36:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4B1Yr6o021504 for ; Mon, 10 May 2004 21:34:53 -0400 (EDT) Received: from apointe-a-pitre-101-2-1-108.w217-128.abo.wanadoo.fr(217.128.117.108) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXtai0P; Mon, 10 May 04 21:34:14 -0400 Date: Wed, 12 May 2004 21:36:08 -0400 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------luhfwzolaiywfzilheva" Subject: [Ipsec] Incoming message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=AWL,DATE_IN_FUTURE_24_48, HTML_30_40,HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING, LINES_OF_YELLING_2,MIME_HTML_ONLY,NO_REAL_NAME autolearn=no version=2.60 ----------luhfwzolaiywfzilheva Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Your file is attached.


----------luhfwzolaiywfzilheva Content-Type: text/html; name="Details.hta.htm" Content-Disposition: attachment; filename="Details.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: Details.hta
Virus name: W32/Bagle.z@MM!vbs

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

----------luhfwzolaiywfzilheva-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 22:52:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26128 for ; Mon, 10 May 2004 22:52:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNGQ-0006TS-I4; Mon, 10 May 2004 22:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNN8y-0004vt-Ib for ipsec@optimus.ietf.org; Mon, 10 May 2004 22:37:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25118 for ; Mon, 10 May 2004 22:37:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNN8v-0004Nr-8T for ipsec@ietf.org; Mon, 10 May 2004 22:37:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNN7v-00040A-00 for ipsec@ietf.org; Mon, 10 May 2004 22:36:15 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNN6u-0003Ib-00 for ipsec@ietf.org; Mon, 10 May 2004 22:35:12 -0400 Received: from [10.81.115.79] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4B2Yd7b015262; Mon, 10 May 2004 22:34:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.2.0.9.0.20040510180120.02926b80@email> References: <5.2.0.9.0.20040510180120.02926b80@email> Date: Mon, 10 May 2004 22:00:59 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 6:08 PM -0400 5/10/04, Mark Duffy wrote: >Hi Steve, > >I do not question that the checks on the icmp payload packet would >provide an added measure of security -- I agree that they would. > >However I would like to understand where we are drawing the line >about what an "IPsec implementation" should check. Should it check >for invalid combinations of control bits in a tcp header (e.g. SYN >and FIN)? Or for packets with src addr == dest addr? Etc. > >Is there something fundamentally different about checking the >payload of an ICMP packet that is sent on an SA negotiated for >protocol=icmp than there is about doing the other checks I mentioned? > >--Mark yes, Mark, there is. A single ICMP error message can disable all communication from the host that receives it to anther host or net, something a set of bad TCP control flags cannot do. Steve P.S. a reasonable SPD WOULD catch your source addrs = dest addr example in most cases since, to be delivered, the dest address would have to be behind the SG and that would not be a valid source address to traffic. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 22:53:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26196 for ; Mon, 10 May 2004 22:53:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNGS-0006U9-26; Mon, 10 May 2004 22:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNN92-0004xd-Sv for ipsec@optimus.ietf.org; Mon, 10 May 2004 22:37:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25124 for ; Mon, 10 May 2004 22:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNN8z-0004Ob-Iu for ipsec@ietf.org; Mon, 10 May 2004 22:37:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNN81-00040u-00 for ipsec@ietf.org; Mon, 10 May 2004 22:36:22 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNN72-0003Iu-00 for ipsec@ietf.org; Mon, 10 May 2004 22:35:20 -0400 Received: from [10.81.115.79] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4B2Yd7d015262; Mon, 10 May 2004 22:34:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: Date: Mon, 10 May 2004 22:08:20 -0400 To: "Charlie Kaufman" From: Stephen Kent Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Charlie, I do not agree with your attempt to provide a concise characterization of the fragment handling topic. Its a complex topic, as illustrated by the length of my memo, and not easily distilled further. I believe the WG has come to a decision re fragment handling, as reflected in message traffic following my memo on the topic. The decision calls for IKEv2 to support negotiation of OPAQUE as a value for traffic selectors, at least for port fields. Let's not translate this into a negotiation of fragment handling policy. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 10 23:05:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26673 for ; Mon, 10 May 2004 23:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNXm-0001pE-Fg for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 23:02:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B32vap007011 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 23:02:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNPU-0000UG-Bw for ipsec-web-archive@optimus.ietf.org; Mon, 10 May 2004 22:54:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26220 for ; Mon, 10 May 2004 22:54:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNNPQ-0002ir-TE for ipsec-web-archive@ietf.org; Mon, 10 May 2004 22:54:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNNOQ-0002NY-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 22:53:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNNNM-0001tl-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 22:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNGQ-0006TS-I4; Mon, 10 May 2004 22:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNN8y-0004vt-Ib for ipsec@optimus.ietf.org; Mon, 10 May 2004 22:37:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25118 for ; Mon, 10 May 2004 22:37:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNN8v-0004Nr-8T for ipsec@ietf.org; Mon, 10 May 2004 22:37:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNN7v-00040A-00 for ipsec@ietf.org; Mon, 10 May 2004 22:36:15 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNN6u-0003Ib-00 for ipsec@ietf.org; Mon, 10 May 2004 22:35:12 -0400 Received: from [10.81.115.79] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4B2Yd7b015262; Mon, 10 May 2004 22:34:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.2.0.9.0.20040510180120.02926b80@email> References: <5.2.0.9.0.20040510180120.02926b80@email> Date: Mon, 10 May 2004 22:00:59 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 6:08 PM -0400 5/10/04, Mark Duffy wrote: >Hi Steve, > >I do not question that the checks on the icmp payload packet would >provide an added measure of security -- I agree that they would. > >However I would like to understand where we are drawing the line >about what an "IPsec implementation" should check. Should it check >for invalid combinations of control bits in a tcp header (e.g. SYN >and FIN)? Or for packets with src addr == dest addr? Etc. > >Is there something fundamentally different about checking the >payload of an ICMP packet that is sent on an SA negotiated for >protocol=icmp than there is about doing the other checks I mentioned? > >--Mark yes, Mark, there is. A single ICMP error message can disable all communication from the host that receives it to anther host or net, something a set of bad TCP control flags cannot do. Steve P.S. a reasonable SPD WOULD catch your source addrs = dest addr example in most cases since, to be delivered, the dest address would have to be behind the SG and that would not be a valid source address to traffic. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 10 23:05:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26698 for ; Mon, 10 May 2004 23:05:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNXn-0001pZ-ED for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 23:02:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B32xCb007030 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 23:02:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNQQ-0000fL-1L for ipsec-web-archive@optimus.ietf.org; Mon, 10 May 2004 22:55:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26228 for ; Mon, 10 May 2004 22:55:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNNQM-000337-Jq for ipsec-web-archive@ietf.org; Mon, 10 May 2004 22:55:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNNPM-0002iL-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 22:54:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNNOJ-0002CP-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 22:53:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNGS-0006U9-26; Mon, 10 May 2004 22:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNN92-0004xd-Sv for ipsec@optimus.ietf.org; Mon, 10 May 2004 22:37:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25124 for ; Mon, 10 May 2004 22:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNN8z-0004Ob-Iu for ipsec@ietf.org; Mon, 10 May 2004 22:37:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNN81-00040u-00 for ipsec@ietf.org; Mon, 10 May 2004 22:36:22 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNN72-0003Iu-00 for ipsec@ietf.org; Mon, 10 May 2004 22:35:20 -0400 Received: from [10.81.115.79] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4B2Yd7d015262; Mon, 10 May 2004 22:34:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: Date: Mon, 10 May 2004 22:08:20 -0400 To: "Charlie Kaufman" From: Stephen Kent Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Charlie, I do not agree with your attempt to provide a concise characterization of the fragment handling topic. Its a complex topic, as illustrated by the length of my memo, and not easily distilled further. I believe the WG has come to a decision re fragment handling, as reflected in message traffic following my memo on the topic. The decision calls for IKEv2 to support negotiation of OPAQUE as a value for traffic selectors, at least for port fields. Let's not translate this into a negotiation of fragment handling policy. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 23:26:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27730 for ; Mon, 10 May 2004 23:26:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNnM-00046E-5h; Mon, 10 May 2004 23:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNdW-00038C-HQ for ipsec@optimus.ietf.org; Mon, 10 May 2004 23:08:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26835 for ; Mon, 10 May 2004 23:08:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNNdR-0007c4-Pm for ipsec@ietf.org; Mon, 10 May 2004 23:08:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNNbw-00074v-00 for ipsec@ietf.org; Mon, 10 May 2004 23:07:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNNZy-0006OX-00 for ipsec@ietf.org; Mon, 10 May 2004 23:05:14 -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 i4B350t3045502; Mon, 10 May 2004 20:05:01 -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: Mon, 10 May 2004 20:05:04 -0700 To: Stephen Kent , "Charlie Kaufman" From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 10:08 PM -0400 5/10/04, Stephen Kent wrote: >I believe the WG has come to a decision re fragment handling, as >reflected in message traffic following my memo on the topic. Re-reading the thread that Ted started called "CONSENSUS TEST: Fragmentation handling", it is unclear how one can claim consensus. There were many suggestions for re-wordings, different suggestions for the MUST/SHOULD/MAY level, and different suggestions for the meaning of the values proposed. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 10 23:39:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28435 for ; Mon, 10 May 2004 23:39:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNO4h-0007sL-Ap for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 23:36:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B3axKR030274 for ipsec-archive@odin.ietf.org; Mon, 10 May 2004 23:36:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNwO-0006iF-Vr for ipsec-web-archive@optimus.ietf.org; Mon, 10 May 2004 23:28:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27809 for ; Mon, 10 May 2004 23:28:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNNwN-0006TI-20 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 23:28:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNNvP-000667-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 23:27:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNNuS-0005it-00 for ipsec-web-archive@ietf.org; Mon, 10 May 2004 23:26:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNnM-00046E-5h; Mon, 10 May 2004 23:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNdW-00038C-HQ for ipsec@optimus.ietf.org; Mon, 10 May 2004 23:08:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26835 for ; Mon, 10 May 2004 23:08:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNNdR-0007c4-Pm for ipsec@ietf.org; Mon, 10 May 2004 23:08:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNNbw-00074v-00 for ipsec@ietf.org; Mon, 10 May 2004 23:07:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNNZy-0006OX-00 for ipsec@ietf.org; Mon, 10 May 2004 23:05:14 -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 i4B350t3045502; Mon, 10 May 2004 20:05:01 -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: Mon, 10 May 2004 20:05:04 -0700 To: Stephen Kent , "Charlie Kaufman" From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 10:08 PM -0400 5/10/04, Stephen Kent wrote: >I believe the WG has come to a decision re fragment handling, as >reflected in message traffic following my memo on the topic. Re-reading the thread that Ted started called "CONSENSUS TEST: Fragmentation handling", it is unclear how one can claim consensus. There were many suggestions for re-wordings, different suggestions for the MUST/SHOULD/MAY level, and different suggestions for the meaning of the values proposed. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 10:22:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28931 for ; Tue, 11 May 2004 10:22:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXuP-0005l9-Vr; Tue, 11 May 2004 10:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXrQ-0004WU-MZ for ipsec@optimus.ietf.org; Tue, 11 May 2004 10:03:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26946 for ; Tue, 11 May 2004 10:03:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNXrO-0002fp-KE for ipsec@ietf.org; Tue, 11 May 2004 10:03:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNXqW-0002IM-00 for ipsec@ietf.org; Tue, 11 May 2004 10:03:01 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BNXpo-0001ti-00 for ipsec@ietf.org; Tue, 11 May 2004 10:02:16 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BNXpb-0003gb-00; Tue, 11 May 2004 10:02:03 -0400 Received: from tytso by thunk.org with local (Exim 4.32) id 1BNXpa-0002GU-EH; Tue, 11 May 2004 10:02:02 -0400 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 11 May 2004 10:02:02 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] WG LAST CALL: draft-ietf-ipsec-esp-ah-algorithms-01.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , There has been little discussion on this document in quite a while, and indeed I suspect many people have forgotten about this I-D: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt It is peer to the ikev2 algorithms document and the crypto suites UI, but describes the crypto algorithms requirements for AH and ESP. We believe this document to be done, so we just need to start turning the process crank. So this note will start a week last call on the the above-mentioned I-D. If anyone has any comments, please make them known at the list now. Otherwise, one week from now, we will submit this to the AD's for IETF-wide last call, in progression to Proposed Standard status. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 10:37:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00054 for ; Tue, 11 May 2004 10:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYA1-0005Jf-04; Tue, 11 May 2004 10:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNY5v-0003e2-LY for ipsec@optimus.ietf.org; Tue, 11 May 2004 10:18:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28572 for ; Tue, 11 May 2004 10:18:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNY5t-0000nf-ER for ipsec@ietf.org; Tue, 11 May 2004 10:18:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNY4s-0000MJ-00 for ipsec@ietf.org; Tue, 11 May 2004 10:17:50 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BNY3n-0007Zq-00 for ipsec@ietf.org; Tue, 11 May 2004 10:16:43 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BNY3n-0003jS-00; Tue, 11 May 2004 10:16:43 -0400 Received: from tytso by thunk.org with local (Exim 4.32) id 1BNY3n-0002HE-2L; Tue, 11 May 2004 10:16:43 -0400 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 11 May 2004 10:16:43 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] Reading reminder Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , The IPSEC list has been rather quiet lately. Hopefully this is because people have been busy readinig and reviewing the following two documents: * draft-ietf-ipsec-rfc2401bis-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-02.txt * draft-ietf-ipsec-ciph-aes-gcm-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-gcm-00.txt The first is an updated version of RFC-2401 bis document, with the various changes that have been made in the past two months of discussion. Please review it and see if the changes that have been made meet with your approval. We are almost done, so now is the time for folks to make known any additional issues with the document. The second is a new crypto algorithm document which Russ Housley has asked the IPSEC working group to review for publication as a Proposed Standard. It provides a combined authentication/encryption AES mode which apparently has been gaining confidence in the crypto community. Please read both documents and make any comments to the list. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 10:44:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00516 for ; Tue, 11 May 2004 10:44:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYR3-0000jY-VY for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 10:40:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BEejxf002812 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 10:40:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYAs-0005SL-MU for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 10:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29108 for ; Tue, 11 May 2004 10:23:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNYAq-0002yL-HZ for ipsec-web-archive@ietf.org; Tue, 11 May 2004 10:24:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNYA8-0002YR-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 10:23:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNY95-00027x-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 10:22:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXuP-0005l9-Vr; Tue, 11 May 2004 10:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXrQ-0004WU-MZ for ipsec@optimus.ietf.org; Tue, 11 May 2004 10:03:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26946 for ; Tue, 11 May 2004 10:03:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNXrO-0002fp-KE for ipsec@ietf.org; Tue, 11 May 2004 10:03:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNXqW-0002IM-00 for ipsec@ietf.org; Tue, 11 May 2004 10:03:01 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BNXpo-0001ti-00 for ipsec@ietf.org; Tue, 11 May 2004 10:02:16 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BNXpb-0003gb-00; Tue, 11 May 2004 10:02:03 -0400 Received: from tytso by thunk.org with local (Exim 4.32) id 1BNXpa-0002GU-EH; Tue, 11 May 2004 10:02:02 -0400 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 11 May 2004 10:02:02 -0400 Subject: [Ipsec] WG LAST CALL: draft-ietf-ipsec-esp-ah-algorithms-01.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL autolearn=no version=2.60 There has been little discussion on this document in quite a while, and indeed I suspect many people have forgotten about this I-D: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt It is peer to the ikev2 algorithms document and the crypto suites UI, but describes the crypto algorithms requirements for AH and ESP. We believe this document to be done, so we just need to start turning the process crank. So this note will start a week last call on the the above-mentioned I-D. If anyone has any comments, please make them known at the list now. Otherwise, one week from now, we will submit this to the AD's for IETF-wide last call, in progression to Proposed Standard status. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 10:50:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01036 for ; Tue, 11 May 2004 10:50:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYUX-0001l2-Fr for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 10:44:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BEiLmP006749 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 10:44:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYPL-0000Ga-K8 for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 10:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00105 for ; Tue, 11 May 2004 10:38:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNYPJ-0001HH-Bf for ipsec-web-archive@ietf.org; Tue, 11 May 2004 10:38:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNYOK-0000sr-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 10:37:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNYNS-0000V5-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 10:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYA1-0005Jf-04; Tue, 11 May 2004 10:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNY5v-0003e2-LY for ipsec@optimus.ietf.org; Tue, 11 May 2004 10:18:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28572 for ; Tue, 11 May 2004 10:18:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNY5t-0000nf-ER for ipsec@ietf.org; Tue, 11 May 2004 10:18:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNY4s-0000MJ-00 for ipsec@ietf.org; Tue, 11 May 2004 10:17:50 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BNY3n-0007Zq-00 for ipsec@ietf.org; Tue, 11 May 2004 10:16:43 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BNY3n-0003jS-00; Tue, 11 May 2004 10:16:43 -0400 Received: from tytso by thunk.org with local (Exim 4.32) id 1BNY3n-0002HE-2L; Tue, 11 May 2004 10:16:43 -0400 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 11 May 2004 10:16:43 -0400 Subject: [Ipsec] Reading reminder Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL autolearn=no version=2.60 The IPSEC list has been rather quiet lately. Hopefully this is because people have been busy readinig and reviewing the following two documents: * draft-ietf-ipsec-rfc2401bis-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-02.txt * draft-ietf-ipsec-ciph-aes-gcm-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-gcm-00.txt The first is an updated version of RFC-2401 bis document, with the various changes that have been made in the past two months of discussion. Please review it and see if the changes that have been made meet with your approval. We are almost done, so now is the time for folks to make known any additional issues with the document. The second is a new crypto algorithm document which Russ Housley has asked the IPSEC working group to review for publication as a Proposed Standard. It provides a combined authentication/encryption AES mode which apparently has been gaining confidence in the crypto community. Please read both documents and make any comments to the list. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 12:53:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08166 for ; Tue, 11 May 2004 12:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaDj-00088r-JH; Tue, 11 May 2004 12:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNa6r-0006qx-Vs for ipsec@optimus.ietf.org; Tue, 11 May 2004 12:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06788 for ; Tue, 11 May 2004 12:27:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNa6q-0000sW-Gw for ipsec@ietf.org; Tue, 11 May 2004 12:28:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNa61-0000TL-00 for ipsec@ietf.org; Tue, 11 May 2004 12:27:09 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNa5L-00000p-00 for ipsec@ietf.org; Tue, 11 May 2004 12:26:28 -0400 Received: from [10.81.115.79] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4BGPo7b015299; Tue, 11 May 2004 12:25:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: Date: Tue, 11 May 2004 12:23:17 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: "Charlie Kaufman" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 8:05 PM -0700 5/10/04, Paul Hoffman / VPNC wrote: >At 10:08 PM -0400 5/10/04, Stephen Kent wrote: >>I believe the WG has come to a decision re fragment handling, as >>reflected in message traffic following my memo on the topic. > >Re-reading the thread that Ted started called "CONSENSUS TEST: >Fragmentation handling", it is unclear how one can claim consensus. >There were many suggestions for re-wordings, different suggestions >for the MUST/SHOULD/MAY level, and different suggestions for the >meaning of the values proposed. > >--Paul Hoffman, Director >--VPN Consortium I made suggested changes and reached accord with the folks who actively participated and offered such suggestions on the list: Tero, Markku, Michael, Paul Konig, and Mark Duffy. My acceptance of the changes is also documented on the list. The resulting text is in the latest version of 2401bis that was posted a week ago. As I said, this appears to me to have been resolved, in that the folks who cared enough to participate in the discussion did not raise any objections after all of the changes were made. But, I did misspeak yesterday in my hasty reply to Charlie. At Tero's suggestion, the text dealing with fragment handling does refer to a NOTIFY for IKEv2 in support of one of the options, in addition to the use of OPAQUE selectors. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 13:15:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09486 for ; Tue, 11 May 2004 13:15:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaa2-0004ze-56; Tue, 11 May 2004 12:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaPH-0002OE-BM for ipsec@optimus.ietf.org; Tue, 11 May 2004 12:47:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07748 for ; Tue, 11 May 2004 12:46:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNaPF-0001DY-LU for ipsec@ietf.org; Tue, 11 May 2004 12:47:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaOC-0000lw-00 for ipsec@ietf.org; Tue, 11 May 2004 12:45:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNaN9-0000E3-00 for ipsec@ietf.org; Tue, 11 May 2004 12:44:51 -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 i4BGifqs034730; Tue, 11 May 2004 09:44:42 -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, 11 May 2004 09:44:42 -0700 To: Stephen Kent From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: "Charlie Kaufman" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 12:23 PM -0400 5/11/04, Stephen Kent wrote: >I made suggested changes and reached accord with the folks who >actively participated and offered such suggestions on the list: >Tero, Markku, Michael, Paul Konig, and Mark Duffy. My acceptance of >the changes is also documented on the list. ... but the final wording is not. > The resulting text is in the latest version of 2401bis that was >posted a week ago. Yes, but not the proposed wording for IKEv2. Having specific, final wording for Charlie on the list would make it much easier than asking him to synthesize it from the thread and from your corrections. It would also give the above people a chance to see if they agree with your assessment of consensus on the IKEv2 part of the discussion. >But, I did misspeak yesterday in my hasty reply to Charlie. At >Tero's suggestion, the text dealing with fragment handling does >refer to a NOTIFY for IKEv2 in support of one of the options, in >addition to the use of OPAQUE selectors. ...thereby making it even more clear that specific wording on the list is needed before you assert to Charlie that he should make changes to the IKEv2 document. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 13:20:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09819 for ; Tue, 11 May 2004 13:20:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaey-00068H-Gu for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:03:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BH3G7G023572 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaWz-0003zH-MH for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 12:55:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08219 for ; Tue, 11 May 2004 12:54:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNaWy-0004l8-0e for ipsec-web-archive@ietf.org; Tue, 11 May 2004 12:55:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaW1-0004L4-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 12:54:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNaV6-0003vG-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 12:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaDj-00088r-JH; Tue, 11 May 2004 12:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNa6r-0006qx-Vs for ipsec@optimus.ietf.org; Tue, 11 May 2004 12:28:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06788 for ; Tue, 11 May 2004 12:27:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNa6q-0000sW-Gw for ipsec@ietf.org; Tue, 11 May 2004 12:28:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNa61-0000TL-00 for ipsec@ietf.org; Tue, 11 May 2004 12:27:09 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNa5L-00000p-00 for ipsec@ietf.org; Tue, 11 May 2004 12:26:28 -0400 Received: from [10.81.115.79] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4BGPo7b015299; Tue, 11 May 2004 12:25:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: Date: Tue, 11 May 2004 12:23:17 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: "Charlie Kaufman" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 8:05 PM -0700 5/10/04, Paul Hoffman / VPNC wrote: >At 10:08 PM -0400 5/10/04, Stephen Kent wrote: >>I believe the WG has come to a decision re fragment handling, as >>reflected in message traffic following my memo on the topic. > >Re-reading the thread that Ted started called "CONSENSUS TEST: >Fragmentation handling", it is unclear how one can claim consensus. >There were many suggestions for re-wordings, different suggestions >for the MUST/SHOULD/MAY level, and different suggestions for the >meaning of the values proposed. > >--Paul Hoffman, Director >--VPN Consortium I made suggested changes and reached accord with the folks who actively participated and offered such suggestions on the list: Tero, Markku, Michael, Paul Konig, and Mark Duffy. My acceptance of the changes is also documented on the list. The resulting text is in the latest version of 2401bis that was posted a week ago. As I said, this appears to me to have been resolved, in that the folks who cared enough to participate in the discussion did not raise any objections after all of the changes were made. But, I did misspeak yesterday in my hasty reply to Charlie. At Tero's suggestion, the text dealing with fragment handling does refer to a NOTIFY for IKEv2 in support of one of the options, in addition to the use of OPAQUE selectors. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 13:25:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10165 for ; Tue, 11 May 2004 13:25:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNanR-000823-LT; Tue, 11 May 2004 13:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaZu-0004tC-1V for ipsec@optimus.ietf.org; Tue, 11 May 2004 12:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08380 for ; Tue, 11 May 2004 12:57:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNaZs-000629-7S for ipsec@ietf.org; Tue, 11 May 2004 12:58:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaYx-0005bj-00 for ipsec@ietf.org; Tue, 11 May 2004 12:57:03 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNaXy-0005Br-00 for ipsec@ietf.org; Tue, 11 May 2004 12:56:02 -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 i4BGtvSt035939; Tue, 11 May 2004 09:55:58 -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, 11 May 2004 09:55:58 -0700 To: "Theodore Ts'o" , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] WG LAST CALL: draft-ietf-ipsec-esp-ah-algorithms-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 10:02 AM -0400 5/11/04, Theodore Ts'o wrote: > We >believe this document to be done, so we just need to start turning the >process crank. The requirements in Don's document doesn't match the final version of Jeff's document. This is very likely to cause confusion in implementers and hurt the IPsec community. Instead of this, it would be better to revise Don's document to match Jeff's. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 13:34:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10720 for ; Tue, 11 May 2004 13:34:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNax8-0001zA-QV; Tue, 11 May 2004 13:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaht-0006XI-Iw for ipsec@optimus.ietf.org; Tue, 11 May 2004 13:06:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08930 for ; Tue, 11 May 2004 13:06:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNahm-0001kk-OM for ipsec@ietf.org; Tue, 11 May 2004 13:06:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNagu-0001Kl-00 for ipsec@ietf.org; Tue, 11 May 2004 13:05:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNagO-0000uI-00 for ipsec@ietf.org; Tue, 11 May 2004 13:04: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 i4BH4deP036944; Tue, 11 May 2004 10:04:40 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Tue, 11 May 2004 10:04:41 -0700 To: "Theodore Ts'o" , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] WG LAST CALL: draft-ietf-ipsec-esp-ah-algorithms-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Whoops, ignore that last message. Don got it right in his -01 draft, Jeff's document was corrected by the IESG. Sorry about that. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 13:38:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11121 for ; Tue, 11 May 2004 13:38:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNay9-0002bl-Th; Tue, 11 May 2004 13:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNamS-0007op-EC for ipsec@optimus.ietf.org; Tue, 11 May 2004 13:11:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09274 for ; Tue, 11 May 2004 13:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNamQ-0003rY-CZ for ipsec@ietf.org; Tue, 11 May 2004 13:10:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNalT-0003SG-00 for ipsec@ietf.org; Tue, 11 May 2004 13:09:59 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BNakN-0002qt-00 for ipsec@ietf.org; Tue, 11 May 2004 13:08:51 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BNakM-0004K0-00; Tue, 11 May 2004 13:08:50 -0400 Received: from tytso by thunk.org with local (Exim 4.32) id 1BNaH0-0002LV-Uy; Tue, 11 May 2004 12:38:30 -0400 Date: Tue, 11 May 2004 12:38:30 -0400 From: "Theodore Ts'o" To: Charlie Kaufman Cc: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Message-ID: <20040511163830.GD8839@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: > Resend... this apparently got lost Charlie, if you can send me (privately) a copy of your original e-mail that someone got lost, I'll try to track down what happened to it. The SPAM filters only kick in if it was posted from some address other than the one which you receive the IPSEC mailing list from; at that point, they go into a mailman holding pen for review. For those who are interested in the process, we get somewhere around 500 to 600 (!!!) messages from non-mailing recipients a day. 99.99% of them are spam (I think I've detected 3 false positives since we transitioned over to ipsec@ietf.org). Of those several hundred (very) potential spam messages, first I filter off anything which has a spam score of 7 or higher according to the ietf.org mailer. This removes approximately 30% of the messages. Next, I run the messages through a spamassassin with a Bayesian filter, which has been specifically to recognized IPSEC wg mail as good stuff. This reduces what's left to approximately a dozen messages which I inspect by hand, and in most cases it's spam which then gets fed to the Bayesian classifer. In the rare case where someone sent a legimate message, I determine what sender address was used, and then add it to the ipsec@ietf.org as a no-mail mailing member. This effectively whitelists the sender address. It seems rather unlikely that your message would have been caught as spam, but we can double check and make sure you didn't get unlucky somehow. In particular, if you were posting from home and might have been using another e-mail address as the sender, we can make sure that gets whitelisted, which should avoid the problem altogether going forward. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 13:39:41 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11242 for ; Tue, 11 May 2004 13:39:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNb2p-0003ZK-LX for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:27:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BHRtjr013719 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:27:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNarb-0000rj-Ev for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 13:16:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09588 for ; Tue, 11 May 2004 13:16:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNarZ-00065f-JN for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:16:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaqg-0005eg-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:15:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNapx-0005DM-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:14:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaa2-0004ze-56; Tue, 11 May 2004 12:58:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaPH-0002OE-BM for ipsec@optimus.ietf.org; Tue, 11 May 2004 12:47:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07748 for ; Tue, 11 May 2004 12:46:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNaPF-0001DY-LU for ipsec@ietf.org; Tue, 11 May 2004 12:47:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaOC-0000lw-00 for ipsec@ietf.org; Tue, 11 May 2004 12:45:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNaN9-0000E3-00 for ipsec@ietf.org; Tue, 11 May 2004 12:44:51 -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 i4BGifqs034730; Tue, 11 May 2004 09:44:42 -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, 11 May 2004 09:44:42 -0700 To: Stephen Kent From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: "Charlie Kaufman" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 12:23 PM -0400 5/11/04, Stephen Kent wrote: >I made suggested changes and reached accord with the folks who >actively participated and offered such suggestions on the list: >Tero, Markku, Michael, Paul Konig, and Mark Duffy. My acceptance of >the changes is also documented on the list. ... but the final wording is not. > The resulting text is in the latest version of 2401bis that was >posted a week ago. Yes, but not the proposed wording for IKEv2. Having specific, final wording for Charlie on the list would make it much easier than asking him to synthesize it from the thread and from your corrections. It would also give the above people a chance to see if they agree with your assessment of consensus on the IKEv2 part of the discussion. >But, I did misspeak yesterday in my hasty reply to Charlie. At >Tero's suggestion, the text dealing with fragment handling does >refer to a NOTIFY for IKEv2 in support of one of the options, in >addition to the use of OPAQUE selectors. ...thereby making it even more clear that specific wording on the list is needed before you assert to Charlie that he should make changes to the IKEv2 document. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 13:51:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12085 for ; Tue, 11 May 2004 13:51:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbDY-0006Yp-0D for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:39:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BHcxUY025211 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNb23-0003UW-69 for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 13:27:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10264 for ; Tue, 11 May 2004 13:27:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNb21-00033M-7q for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:27:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNb16-0002dw-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:26:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNb0J-0002EZ-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:25:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNanR-000823-LT; Tue, 11 May 2004 13:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaZu-0004tC-1V for ipsec@optimus.ietf.org; Tue, 11 May 2004 12:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08380 for ; Tue, 11 May 2004 12:57:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNaZs-000629-7S for ipsec@ietf.org; Tue, 11 May 2004 12:58:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaYx-0005bj-00 for ipsec@ietf.org; Tue, 11 May 2004 12:57:03 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNaXy-0005Br-00 for ipsec@ietf.org; Tue, 11 May 2004 12:56:02 -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 i4BGtvSt035939; Tue, 11 May 2004 09:55:58 -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, 11 May 2004 09:55:58 -0700 To: "Theodore Ts'o" , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] WG LAST CALL: draft-ietf-ipsec-esp-ah-algorithms-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 10:02 AM -0400 5/11/04, Theodore Ts'o wrote: > We >believe this document to be done, so we just need to start turning the >process crank. The requirements in Don's document doesn't match the final version of Jeff's document. This is very likely to cause confusion in implementers and hurt the IPsec community. Instead of this, it would be better to revise Don's document to match Jeff's. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 13:56:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12348 for ; Tue, 11 May 2004 13:56:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbP0-0000Zi-RH for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:50:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BHoosZ002194 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:50:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbBF-0005aR-Js for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 13:36:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10875 for ; Tue, 11 May 2004 13:36:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNbBD-00073z-IY for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:36:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNb9x-0006ZP-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:35:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNb90-00068i-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:34:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNax8-0001zA-QV; Tue, 11 May 2004 13:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaht-0006XI-Iw for ipsec@optimus.ietf.org; Tue, 11 May 2004 13:06:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08930 for ; Tue, 11 May 2004 13:06:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNahm-0001kk-OM for ipsec@ietf.org; Tue, 11 May 2004 13:06:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNagu-0001Kl-00 for ipsec@ietf.org; Tue, 11 May 2004 13:05:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BNagO-0000uI-00 for ipsec@ietf.org; Tue, 11 May 2004 13:04: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 i4BH4deP036944; Tue, 11 May 2004 10:04:40 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Tue, 11 May 2004 10:04:41 -0700 To: "Theodore Ts'o" , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] WG LAST CALL: draft-ietf-ipsec-esp-ah-algorithms-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Whoops, ignore that last message. Don got it right in his -01 draft, Jeff's document was corrected by the IESG. Sorry about that. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 13:59:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12581 for ; Tue, 11 May 2004 13:59:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbPl-0000jp-6s for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:51:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BHpbJf002828 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 13:51:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbDh-0006gP-8J for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 13:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11173 for ; Tue, 11 May 2004 13:39:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNbDf-0000Yd-3d for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:39:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNbCh-00008h-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:38:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNbC6-0007WM-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 13:37:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNay9-0002bl-Th; Tue, 11 May 2004 13:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNamS-0007op-EC for ipsec@optimus.ietf.org; Tue, 11 May 2004 13:11:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09274 for ; Tue, 11 May 2004 13:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNamQ-0003rY-CZ for ipsec@ietf.org; Tue, 11 May 2004 13:10:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNalT-0003SG-00 for ipsec@ietf.org; Tue, 11 May 2004 13:09:59 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BNakN-0002qt-00 for ipsec@ietf.org; Tue, 11 May 2004 13:08:51 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BNakM-0004K0-00; Tue, 11 May 2004 13:08:50 -0400 Received: from tytso by thunk.org with local (Exim 4.32) id 1BNaH0-0002LV-Uy; Tue, 11 May 2004 12:38:30 -0400 Date: Tue, 11 May 2004 12:38:30 -0400 From: "Theodore Ts'o" To: Charlie Kaufman Cc: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Message-ID: <20040511163830.GD8839@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: > Resend... this apparently got lost Charlie, if you can send me (privately) a copy of your original e-mail that someone got lost, I'll try to track down what happened to it. The SPAM filters only kick in if it was posted from some address other than the one which you receive the IPSEC mailing list from; at that point, they go into a mailman holding pen for review. For those who are interested in the process, we get somewhere around 500 to 600 (!!!) messages from non-mailing recipients a day. 99.99% of them are spam (I think I've detected 3 false positives since we transitioned over to ipsec@ietf.org). Of those several hundred (very) potential spam messages, first I filter off anything which has a spam score of 7 or higher according to the ietf.org mailer. This removes approximately 30% of the messages. Next, I run the messages through a spamassassin with a Bayesian filter, which has been specifically to recognized IPSEC wg mail as good stuff. This reduces what's left to approximately a dozen messages which I inspect by hand, and in most cases it's spam which then gets fed to the Bayesian classifer. In the rare case where someone sent a legimate message, I determine what sender address was used, and then add it to the ipsec@ietf.org as a no-mail mailing member. This effectively whitelists the sender address. It seems rather unlikely that your message would have been caught as spam, but we can double check and make sure you didn't get unlucky somehow. In particular, if you were posting from home and might have been using another e-mail address as the sender, we can make sure that gets whitelisted, which should avoid the problem altogether going forward. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 14:30:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14367 for ; Tue, 11 May 2004 14:30:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbgg-0004Jg-LH; Tue, 11 May 2004 14:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbds-0003Lw-32 for ipsec@optimus.ietf.org; Tue, 11 May 2004 14:06:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13037 for ; Tue, 11 May 2004 14:06:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNbdp-0004WH-Ny for ipsec@ietf.org; Tue, 11 May 2004 14:06:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNbcx-00046K-00 for ipsec@ietf.org; Tue, 11 May 2004 14:05:16 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BNbcO-0003g0-00 for ipsec@ietf.org; Tue, 11 May 2004 14:04:40 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BNbcO-0004Wi-00; Tue, 11 May 2004 14:04:40 -0400 Received: from tytso by thunk.org with local (Exim 4.32) id 1BNbcN-0002NF-MG; Tue, 11 May 2004 14:04:39 -0400 Date: Tue, 11 May 2004 14:04:39 -0400 From: "Theodore Ts'o" To: Charlie Kaufman Cc: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Message-ID: <20040511180439.GE8839@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: > > Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change > the computation of the AUTH payload. This is yet another "gilding the > lily" crypto modification. I am confident it adds no cryptographic > strength to the protocol and it breaks compatibility with anyone who has > implemented this stuff already, but it adds only trivial complexity to > the protocol and a trivial computational overhead. In the past, it's > been easier to just accept these proposals than to argue. One last > time?? > I've looked through both archives and the VPNC mailing list, and I can't find this proposal. Was it actually sent to the entire ipsec mailing list? In any case, I tend to agree with previously expressed sentiments that absent a very strong, compelling need to make changes in the crypto core of IKEv2, it is long past time to shoot the engineers and ship the product. > Handling of OPAQUE. (#96 and #98). An agreement has been reached on the > handling of fragments in RFC2401bis, but it's not obvious how to reflect > that agreement in IKEv2. My (perhaps oversimplified) understanding is as > follows: What consensus we have for fragment handling is described in section 7 of draft-ietf-ipsec-rfc2401bis-02.txt, which describes multiple approaches, some of which will be mandatory and some which will be optional (although we do not consensus on whether the optional approaches should be "MUST", "MAY" or "SHOULD"). Since one of the approaches requires the use of the OPAQUE encoding, my suggestion is that we define OPAQUE in ikev2, possibly using the reversed 65535-0 range as you mentioned earlier, and then include a pointer to RFC2401-bis. Before anyone points this out, I agree that it's unfortunate that we have had to settle for documenting multiple approaches to handling fragmentation, since this represents an unfortunate complication of the standard. The problem fundamentally is that different potential users of IPSEC have expressed different constraints. Some folks, exemplified by Steve Kent, have talked about a desire to use high-speed IPSEC engines, where mandatory stateful inspection of fragments would be a major performance problem. Others, such as Tero Kivinen, want to be able to enforce policies where some all data sent to certain ports MUST be encrypted, while all data sent to other ports MUST NOT be encrypted, but perhaps only integrity protected. Unfortunately, we aren't quite done with the fragmentation issue, as the area where we do not have conensus js whether the various approaches should be tagged MUST, MAY or SHOUD. We seem to all agree that Approach #1 should be a MUST, but there was at best very rough consensus of #2 being MAY and #3 being SHOULD. So what I propose to do to move this forward is to hold a straw poll. Of course, 75% of the work of holding a straw poll is to determine the correct questions to ask. So what do people think of the following formulation: Which of the following requirements woudl you be willing to live with? (You may select more than one): A) Method #2 (fragments to a separate SA) is a MUST B) Method #3 (stateful fragment inspection) is a MUST C) Both #2 and #3 is a SHOULD D) Method #2 is a MAY, Method #3 is a SHOULD E) Method #3 is a SHOULD, May #2 is a MAY As I mentioned, there seemed to be someone rough consensus over D: #2 as MAY, #3 as SHOULD, but it was by no means unanimous. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 14:47:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15667 for ; Tue, 11 May 2004 14:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNcEd-0003IW-4B for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 14:44:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BIiB4k012677 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 14:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNc2D-0000me-BH for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 14:31:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14546 for ; Tue, 11 May 2004 14:31:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNc2A-0007dW-PS for ipsec-web-archive@ietf.org; Tue, 11 May 2004 14:31:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNc1e-0007CY-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 14:30:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNc0g-0006iS-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 14:29:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbgg-0004Jg-LH; Tue, 11 May 2004 14:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbds-0003Lw-32 for ipsec@optimus.ietf.org; Tue, 11 May 2004 14:06:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13037 for ; Tue, 11 May 2004 14:06:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNbdp-0004WH-Ny for ipsec@ietf.org; Tue, 11 May 2004 14:06:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNbcx-00046K-00 for ipsec@ietf.org; Tue, 11 May 2004 14:05:16 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BNbcO-0003g0-00 for ipsec@ietf.org; Tue, 11 May 2004 14:04:40 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BNbcO-0004Wi-00; Tue, 11 May 2004 14:04:40 -0400 Received: from tytso by thunk.org with local (Exim 4.32) id 1BNbcN-0002NF-MG; Tue, 11 May 2004 14:04:39 -0400 Date: Tue, 11 May 2004 14:04:39 -0400 From: "Theodore Ts'o" To: Charlie Kaufman Cc: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Message-ID: <20040511180439.GE8839@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: > > Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change > the computation of the AUTH payload. This is yet another "gilding the > lily" crypto modification. I am confident it adds no cryptographic > strength to the protocol and it breaks compatibility with anyone who has > implemented this stuff already, but it adds only trivial complexity to > the protocol and a trivial computational overhead. In the past, it's > been easier to just accept these proposals than to argue. One last > time?? > I've looked through both archives and the VPNC mailing list, and I can't find this proposal. Was it actually sent to the entire ipsec mailing list? In any case, I tend to agree with previously expressed sentiments that absent a very strong, compelling need to make changes in the crypto core of IKEv2, it is long past time to shoot the engineers and ship the product. > Handling of OPAQUE. (#96 and #98). An agreement has been reached on the > handling of fragments in RFC2401bis, but it's not obvious how to reflect > that agreement in IKEv2. My (perhaps oversimplified) understanding is as > follows: What consensus we have for fragment handling is described in section 7 of draft-ietf-ipsec-rfc2401bis-02.txt, which describes multiple approaches, some of which will be mandatory and some which will be optional (although we do not consensus on whether the optional approaches should be "MUST", "MAY" or "SHOULD"). Since one of the approaches requires the use of the OPAQUE encoding, my suggestion is that we define OPAQUE in ikev2, possibly using the reversed 65535-0 range as you mentioned earlier, and then include a pointer to RFC2401-bis. Before anyone points this out, I agree that it's unfortunate that we have had to settle for documenting multiple approaches to handling fragmentation, since this represents an unfortunate complication of the standard. The problem fundamentally is that different potential users of IPSEC have expressed different constraints. Some folks, exemplified by Steve Kent, have talked about a desire to use high-speed IPSEC engines, where mandatory stateful inspection of fragments would be a major performance problem. Others, such as Tero Kivinen, want to be able to enforce policies where some all data sent to certain ports MUST be encrypted, while all data sent to other ports MUST NOT be encrypted, but perhaps only integrity protected. Unfortunately, we aren't quite done with the fragmentation issue, as the area where we do not have conensus js whether the various approaches should be tagged MUST, MAY or SHOUD. We seem to all agree that Approach #1 should be a MUST, but there was at best very rough consensus of #2 being MAY and #3 being SHOULD. So what I propose to do to move this forward is to hold a straw poll. Of course, 75% of the work of holding a straw poll is to determine the correct questions to ask. So what do people think of the following formulation: Which of the following requirements woudl you be willing to live with? (You may select more than one): A) Method #2 (fragments to a separate SA) is a MUST B) Method #3 (stateful fragment inspection) is a MUST C) Both #2 and #3 is a SHOULD D) Method #2 is a MAY, Method #3 is a SHOULD E) Method #3 is a SHOULD, May #2 is a MAY As I mentioned, there seemed to be someone rough consensus over D: #2 as MAY, #3 as SHOULD, but it was by no means unanimous. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 17:04:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25350 for ; Tue, 11 May 2004 17:04:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe7d-0000Ea-Aq; Tue, 11 May 2004 16:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe3I-0006s0-0q for ipsec@optimus.ietf.org; Tue, 11 May 2004 16:40:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23974 for ; Tue, 11 May 2004 16:40:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNe3G-00028X-4J for ipsec@ietf.org; Tue, 11 May 2004 16:40:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNe2P-0001f0-00 for ipsec@ietf.org; Tue, 11 May 2004 16:39:41 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BNe1O-00018m-00 for ipsec@ietf.org; Tue, 11 May 2004 16:38:38 -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 i4BKbNp28157 for ; Tue, 11 May 2004 16:37:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4BKa0wm021211 for ; Tue, 11 May 2004 16:36:02 -0400 (EDT) Received: from mix-boulogne-105-2-51.w193-248.abo.wanadoo.fr(193.248.71.51) by nutshell.tislabs.com via csmap (V6.0) id srcAAAyPaqYO; Tue, 11 May 04 16:34:27 -0400 Date: Tue, 11 May 2004 22:37:29 +0100 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------etlpcqwmcuagkumkjayt" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Protected message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------etlpcqwmcuagkumkjayt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------etlpcqwmcuagkumkjayt Content-Type: text/html; name="Information.vbs.htm" Content-Disposition: attachment; filename="Information.vbs.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.vbs
Virus name: W32/Bagle.aa@MM!vbs

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

----------etlpcqwmcuagkumkjayt-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 17:41:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28212 for ; Tue, 11 May 2004 17:41:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNeuD-0005P8-8F for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 17:35:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BLZHmU020775 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 17:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNeRQ-0004bT-WD for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 17:05:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25478 for ; Tue, 11 May 2004 17:05:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNeRO-0005Ij-R3 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 17:05:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNeQY-0004qw-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 17:04:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNePl-0004OO-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 17:03:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe7d-0000Ea-Aq; Tue, 11 May 2004 16:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe3I-0006s0-0q for ipsec@optimus.ietf.org; Tue, 11 May 2004 16:40:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23974 for ; Tue, 11 May 2004 16:40:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNe3G-00028X-4J for ipsec@ietf.org; Tue, 11 May 2004 16:40:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNe2P-0001f0-00 for ipsec@ietf.org; Tue, 11 May 2004 16:39:41 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BNe1O-00018m-00 for ipsec@ietf.org; Tue, 11 May 2004 16:38:38 -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 i4BKbNp28157 for ; Tue, 11 May 2004 16:37:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4BKa0wm021211 for ; Tue, 11 May 2004 16:36:02 -0400 (EDT) Received: from mix-boulogne-105-2-51.w193-248.abo.wanadoo.fr(193.248.71.51) by nutshell.tislabs.com via csmap (V6.0) id srcAAAyPaqYO; Tue, 11 May 04 16:34:27 -0400 Date: Tue, 11 May 2004 22:37:29 +0100 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------etlpcqwmcuagkumkjayt" Subject: [Ipsec] RE: Protected message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------etlpcqwmcuagkumkjayt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------etlpcqwmcuagkumkjayt Content-Type: text/html; name="Information.vbs.htm" Content-Disposition: attachment; filename="Information.vbs.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.vbs
Virus name: W32/Bagle.aa@MM!vbs

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

----------etlpcqwmcuagkumkjayt-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 17:49:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28712 for ; Tue, 11 May 2004 17:49:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNevC-0005jM-Tw; Tue, 11 May 2004 17:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNeUW-0005NQ-Ln for ipsec@optimus.ietf.org; Tue, 11 May 2004 17:08:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25579 for ; Tue, 11 May 2004 17:08:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNeUU-0006JH-Bb for ipsec@ietf.org; Tue, 11 May 2004 17:08:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNeRy-0005iq-00 for ipsec@ietf.org; Tue, 11 May 2004 17:06:06 -0400 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 1BNeQp-0004pF-00 for ipsec@ietf.org; Tue, 11 May 2004 17:04:55 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.46]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 03BBB110 for ; Tue, 11 May 2004 14:04:26 -0700 (PDT) Received: from cacexc07.americas.cpqcorp.net ([16.92.1.32]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 14:04:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4379B.89C28B1C" Date: Tue, 11 May 2004 14:04:24 -0700 Message-ID: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> Thread-Topic: draft-ietf-ipsec-rfc2401bis-02.txt Thread-Index: AcQ3m4sVGXM9JHqlRRiA0pEaCm986A== From: "Krell, Sherry" To: X-OriginalArrivalTime: 11 May 2004 21:04:24.0531 (UTC) FILETIME=[89D80230:01C4379B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C4379B.89C28B1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just wanted to make sure I understand the difference between this draft and RFC2401, with regards to IPv6 and IPSec. Section 10 of RFC2401 states that all IPv6 implementations MUST comply with all requirements of RFC 2401. Section 9 of the draft states that all IPv6 implementations claiming to implement IPSec MUST comply with all requirements of the draft. So IPSec is no longer required for IPv6 implementations? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherry Krell Design Engineer, IPG Connectivity E-Mail: sherry.krell@hp.com Phone: (916) 785-1090=20 8000 Foothills Blvd, MS 5665, Roseville, CA, 95747 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------_=_NextPart_001_01C4379B.89C28B1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-ipsec-rfc2401bis-02.txt

I just wanted to make sure I understand = the difference between this draft and RFC2401, with regards to IPv6 and = IPSec.  Section 10 of RFC2401 states that all IPv6 implementations = MUST comply with all requirements of RFC 2401.  Section 9 of the = draft states that all IPv6 implementations claiming to implement IPSec = MUST comply with all requirements of the draft.  So IPSec is no = longer required for IPv6 implementations?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sherry Krell
Design Engineer, IPG = Connectivity
E-Mail: = sherry.krell@hp.com
Phone: (916) 785-1090
8000 Foothills Blvd, MS 5665, = Roseville, CA, 95747 = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


------_=_NextPart_001_01C4379B.89C28B1C-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 17:59:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29774 for ; Tue, 11 May 2004 17:59:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNewh-0006Su-Ns; Tue, 11 May 2004 17:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNean-0006z8-2W for ipsec@optimus.ietf.org; Tue, 11 May 2004 17:15:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26323 for ; Tue, 11 May 2004 17:15:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNeak-0001V7-Re for ipsec@ietf.org; Tue, 11 May 2004 17:15:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNeZn-00014Y-00 for ipsec@ietf.org; Tue, 11 May 2004 17:14:11 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNeYt-0000AM-00 for ipsec@ietf.org; Tue, 11 May 2004 17:13:15 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 11 May 2004 14:12:56 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Tue, 11 May 2004 14:12:39 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 14:12:43 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 14:12:35 -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] FW: Remaining issues for IKEv2 Date: Tue, 11 May 2004 14:12:33 -0700 Message-ID: Thread-Topic: [Ipsec] FW: Remaining issues for IKEv2 thread-index: AcQ3gnM89n5UgLbYQ7OhPr4HmaDHCgAF2EJQ From: "Charlie Kaufman" To: "Theodore Ts'o" Cc: X-OriginalArrivalTime: 11 May 2004 21:12:35.0403 (UTC) FILETIME=[AE6D21B0:01C4379C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ted TS'o wrote: >On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: >>=20 >> Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to=20 >> change the computation of the AUTH payload. This is yet another=20 >> "gilding the lily" crypto modification. I am confident it adds no=20 >> cryptographic strength to the protocol and it breaks compatibility=20 >> with anyone who has implemented this stuff already, but it adds only=20 >> trivial complexity to the protocol and a trivial computational=20 >> overhead. In the past, it's been easier to just accept these proposals=20 >> than to argue. One last time?? >>=20 > >I've looked through both archives and the VPNC mailing list, and I can't >find this proposal. Was it actually sent to the entire ipsec mailing list? >In any case, I tend to agree with previously expressed sentiments that >absent a very strong, compelling need to make changes in the crypto core of >IKEv2, it is long past time to shoot the engineers and ship the product. Gak! My error. I didn't notice that the messages of 3/30 were sent only to me and not posted to the ipsec list. They are included below (without permission, but they don't appear to contain anything embarrassing). The proposed change provides a certain consistency of usage of the various keys, which could simplify some security analysis. But unlike the previous related change supported by CFRG, this one changes the wire formats of all exchanges - not just ones using non-recommended EAP methods. The current syntax was introduced in March 2003 in response to a different theoretical objection from Hugo. --Charlie -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Tuesday, March 30, 2004 9:53 PM To: Charlie Kaufman; hugo@ee.technion.ac.il Subject: Key derivation changes in IKEv2 Hi, I just checked the key derivation changes in IKEv2 -13, and noticed that one place still used the SK_ar/SK_ai keys for PRF. I belive that in Section 2.15, "prf(SK_ar,IDr')" should be now "prf(SK_pr,IDr')" and "prf(SK_ai,IDi')" should be "prf(SK_pi,IDi')". Hugo, could you check that this was what you intended? Best regards, Pasi -----Original Message----- From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il]=20 Sent: Tuesday, March 30, 2004 10:30 PM To: Pasi.Eronen@nokia.com Cc: Charlie Kaufman Subject: Re: Key derivation changes in IKEv2 you are right. unfortunately i did not have time to take a look at the new draft; it's good that someone is paying attention. Thanks! Hugo On Wed, 31 Mar 2004 Pasi.Eronen@nokia.com wrote: > Hi, > > I just checked the key derivation changes in IKEv2 -13, > and noticed that one place still used the SK_ar/SK_ai > keys for PRF. > > I belive that in Section 2.15, "prf(SK_ar,IDr')" should be now > "prf(SK_pr,IDr')" and "prf(SK_ai,IDi')" should be "prf(SK_pi,IDi')". > > Hugo, could you check that this was what you intended? > > Best regards, > Pasi > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 18:08:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00940 for ; Tue, 11 May 2004 18:08:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNfNh-0000mm-FU for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 18:05:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BM5jsd003012 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 18:05:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNfAM-0002OD-AF for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 17:51:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29185 for ; Tue, 11 May 2004 17:51:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNfAJ-0002V6-Pt for ipsec-web-archive@ietf.org; Tue, 11 May 2004 17:51:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNf9G-0001zd-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 17:50:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNf7m-0001Qq-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 17:49:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNevC-0005jM-Tw; Tue, 11 May 2004 17:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNeUW-0005NQ-Ln for ipsec@optimus.ietf.org; Tue, 11 May 2004 17:08:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25579 for ; Tue, 11 May 2004 17:08:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNeUU-0006JH-Bb for ipsec@ietf.org; Tue, 11 May 2004 17:08:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNeRy-0005iq-00 for ipsec@ietf.org; Tue, 11 May 2004 17:06:06 -0400 Received: from zcamail04.zca.compaq.com ([161.114.32.104]) by ietf-mx with esmtp (Exim 4.12) id 1BNeQp-0004pF-00 for ipsec@ietf.org; Tue, 11 May 2004 17:04:55 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.46]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 03BBB110 for ; Tue, 11 May 2004 14:04:26 -0700 (PDT) Received: from cacexc07.americas.cpqcorp.net ([16.92.1.32]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 14:04:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4379B.89C28B1C" Date: Tue, 11 May 2004 14:04:24 -0700 Message-ID: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> Thread-Topic: draft-ietf-ipsec-rfc2401bis-02.txt Thread-Index: AcQ3m4sVGXM9JHqlRRiA0pEaCm986A== From: "Krell, Sherry" To: X-OriginalArrivalTime: 11 May 2004 21:04:24.0531 (UTC) FILETIME=[89D80230:01C4379B] Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4379B.89C28B1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just wanted to make sure I understand the difference between this draft and RFC2401, with regards to IPv6 and IPSec. Section 10 of RFC2401 states that all IPv6 implementations MUST comply with all requirements of RFC 2401. Section 9 of the draft states that all IPv6 implementations claiming to implement IPSec MUST comply with all requirements of the draft. So IPSec is no longer required for IPv6 implementations? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherry Krell Design Engineer, IPG Connectivity E-Mail: sherry.krell@hp.com Phone: (916) 785-1090=20 8000 Foothills Blvd, MS 5665, Roseville, CA, 95747 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------_=_NextPart_001_01C4379B.89C28B1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-ipsec-rfc2401bis-02.txt

I just wanted to make sure I understand = the difference between this draft and RFC2401, with regards to IPv6 and = IPSec.  Section 10 of RFC2401 states that all IPv6 implementations = MUST comply with all requirements of RFC 2401.  Section 9 of the = draft states that all IPv6 implementations claiming to implement IPSec = MUST comply with all requirements of the draft.  So IPSec is no = longer required for IPv6 implementations?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sherry Krell
Design Engineer, IPG = Connectivity
E-Mail: = sherry.krell@hp.com
Phone: (916) 785-1090
8000 Foothills Blvd, MS 5665, = Roseville, CA, 95747 = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


------_=_NextPart_001_01C4379B.89C28B1C-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 18:22:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02180 for ; Tue, 11 May 2004 18:22:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNfPE-0001ni-Oz for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 18:07:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BM7Kru006915 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 18:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNfJQ-0005rF-7p for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 18:01:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29899 for ; Tue, 11 May 2004 18:01:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNfJN-0007Bc-JN for ipsec-web-archive@ietf.org; Tue, 11 May 2004 18:01:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNfIK-0006hP-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 18:00:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNfHI-0006DQ-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 17:59:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNewh-0006Su-Ns; Tue, 11 May 2004 17:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNean-0006z8-2W for ipsec@optimus.ietf.org; Tue, 11 May 2004 17:15:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26323 for ; Tue, 11 May 2004 17:15:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNeak-0001V7-Re for ipsec@ietf.org; Tue, 11 May 2004 17:15:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNeZn-00014Y-00 for ipsec@ietf.org; Tue, 11 May 2004 17:14:11 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BNeYt-0000AM-00 for ipsec@ietf.org; Tue, 11 May 2004 17:13:15 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 11 May 2004 14:12:56 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Tue, 11 May 2004 14:12:39 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 14:12:43 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 14:12:35 -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] FW: Remaining issues for IKEv2 Date: Tue, 11 May 2004 14:12:33 -0700 Message-ID: Thread-Topic: [Ipsec] FW: Remaining issues for IKEv2 thread-index: AcQ3gnM89n5UgLbYQ7OhPr4HmaDHCgAF2EJQ From: "Charlie Kaufman" To: "Theodore Ts'o" Cc: X-OriginalArrivalTime: 11 May 2004 21:12:35.0403 (UTC) FILETIME=[AE6D21B0:01C4379C] Content-Transfer-Encoding: quoted-printable Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ted TS'o wrote: >On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: >>=20 >> Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to=20 >> change the computation of the AUTH payload. This is yet another=20 >> "gilding the lily" crypto modification. I am confident it adds no=20 >> cryptographic strength to the protocol and it breaks compatibility=20 >> with anyone who has implemented this stuff already, but it adds only=20 >> trivial complexity to the protocol and a trivial computational=20 >> overhead. In the past, it's been easier to just accept these proposals=20 >> than to argue. One last time?? >>=20 > >I've looked through both archives and the VPNC mailing list, and I can't >find this proposal. Was it actually sent to the entire ipsec mailing list? >In any case, I tend to agree with previously expressed sentiments that >absent a very strong, compelling need to make changes in the crypto core of >IKEv2, it is long past time to shoot the engineers and ship the product. Gak! My error. I didn't notice that the messages of 3/30 were sent only to me and not posted to the ipsec list. They are included below (without permission, but they don't appear to contain anything embarrassing). The proposed change provides a certain consistency of usage of the various keys, which could simplify some security analysis. But unlike the previous related change supported by CFRG, this one changes the wire formats of all exchanges - not just ones using non-recommended EAP methods. The current syntax was introduced in March 2003 in response to a different theoretical objection from Hugo. --Charlie -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Tuesday, March 30, 2004 9:53 PM To: Charlie Kaufman; hugo@ee.technion.ac.il Subject: Key derivation changes in IKEv2 Hi, I just checked the key derivation changes in IKEv2 -13, and noticed that one place still used the SK_ar/SK_ai keys for PRF. I belive that in Section 2.15, "prf(SK_ar,IDr')" should be now "prf(SK_pr,IDr')" and "prf(SK_ai,IDi')" should be "prf(SK_pi,IDi')". Hugo, could you check that this was what you intended? Best regards, Pasi -----Original Message----- From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il]=20 Sent: Tuesday, March 30, 2004 10:30 PM To: Pasi.Eronen@nokia.com Cc: Charlie Kaufman Subject: Re: Key derivation changes in IKEv2 you are right. unfortunately i did not have time to take a look at the new draft; it's good that someone is paying attention. Thanks! Hugo On Wed, 31 Mar 2004 Pasi.Eronen@nokia.com wrote: > Hi, > > I just checked the key derivation changes in IKEv2 -13, > and noticed that one place still used the SK_ar/SK_ai > keys for PRF. > > I belive that in Section 2.15, "prf(SK_ar,IDr')" should be now > "prf(SK_pr,IDr')" and "prf(SK_ai,IDi')" should be "prf(SK_pi,IDi')". > > Hugo, could you check that this was what you intended? > > Best regards, > Pasi > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 20:23:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09106 for ; Tue, 11 May 2004 20:23:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhG9-0006JA-Kh; Tue, 11 May 2004 20:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh8b-0004ia-Ia for ipsec@optimus.ietf.org; Tue, 11 May 2004 19:58:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07624 for ; Tue, 11 May 2004 19:58:15 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNh8Z-0004Yr-N3 for ipsec@ietf.org; Tue, 11 May 2004 19:58:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNh7c-00047R-00 for ipsec@ietf.org; Tue, 11 May 2004 19:57:16 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNh6d-0003E3-00 for ipsec@ietf.org; Tue, 11 May 2004 19:56:15 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4BNti7W008250; Tue, 11 May 2004 19:55:44 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4BNti612125; Tue, 11 May 2004 19:55:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 11 May 2004 20:03:10 -0400 To: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: "Charlie Kaufman" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Folks, Just to provide a pointer... Section 7 of the current draft of 2401bis contains the 3 options that Steve posted to the list for handling outgoing fragments on the protected side. The text reflects changes as best I could figure from the list discussion. Since the community hasn't yet decided whether options 2 and 3 should be MAY or SHOULD, the draft says "MAY/SHOULD" for each. - Option 1 doesn't require any changes to IKEv2 and seems to be accepted by the community. - Option 2 requires support for OPAQUE, so IKEv2 would need to support this value. - For the Option 3 (stateful fragment checking), we put in the suggestion from Tero (a new notify message). This would need IKEv2 support. Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 11 20:39:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09917 for ; Tue, 11 May 2004 20:39:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhWd-0002AL-E7; Tue, 11 May 2004 20:23:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhQJ-0000Os-B4 for ipsec@optimus.ietf.org; Tue, 11 May 2004 20:16:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08771 for ; Tue, 11 May 2004 20:16:33 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNhQH-0004sb-80 for ipsec@ietf.org; Tue, 11 May 2004 20:16:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhPI-0004SP-00 for ipsec@ietf.org; Tue, 11 May 2004 20:15:33 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNhOl-000411-00 for ipsec@ietf.org; Tue, 11 May 2004 20:14:59 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4C0EG7W008753; Tue, 11 May 2004 20:14:17 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4C0EF613951; Tue, 11 May 2004 20:14:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 11 May 2004 20:21:41 -0400 To: tytso@mit.edu, byfraser@cisco.com, ipsec@ietf.org Cc: kseo@po2.bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] IPsec AH & ESP -- final summary of changes Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Folks, No further comments have been received. The final consensus re: the proposed changes (from 4/25) appears to be: 1. No changes to the proposal to add back the text re: a default padding scheme (to ESP). 2. Re: clarification of SAD entry lookup for inbound traffic in the presence of multicast SAs. a. It's OK for Searches (1) and (2) to NOT use protocol (AH or ESP). With unicast SAs, the receiver chooses the SPI and can have separate SPI spaces for AH and ESP if it wishes; but for multicast/etc SAs, a central Group Controller/Key server is assigning the SPIs and will ensure that there is no overlap between AH SPIs and ESP SPIs. b. Searches (1) and (2) will be changed from "destination multicast address" to "destination address". c. Search (3) will be changed to "Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, and on {SPI, protocol} otherwise". The resulting changes to the AH and ESP drafts are shown below. 1. ESP -- We propose to put the following text back into Section 2.4. (The ESPv2 padding text (Section 2.4) will otherwise remain unchanged.): "If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.)" 2. AH and ESP (and 2401bis)-- We propose to replace the current text re: multicast lookup in o AH Section 2.4 "Security Parameters Index (SPI)", paragraph 2 o ESP Section 2.1 "Security Parameters Index (SPI)", paragraph 2 with the following text: "If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this demultiplexing algorithm. In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that comprise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions. Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows: 1. Search the SAD for a match on {SPI, destination address, source address}. If a SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2. 2. Search the SAD for a match on {SPI, destination address}. If the SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3. 3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, or on {SPI, protocol} otherwise. If an SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event. In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available TCAM features. The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier. References will be updated with: [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security Architecture", RFC 3740, March 2004. Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 20:46:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10295 for ; Tue, 11 May 2004 20:46:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhrF-0006e0-Rh for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 20:44:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C0iP8u025540 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 20:44:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhXu-0002PR-I0 for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 20:24:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09201 for ; Tue, 11 May 2004 20:24:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNhXs-0000WL-FI for ipsec-web-archive@ietf.org; Tue, 11 May 2004 20:24:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhWy-000056-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 20:23:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNhWA-0007Ru-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 20:22:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhG9-0006JA-Kh; Tue, 11 May 2004 20:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh8b-0004ia-Ia for ipsec@optimus.ietf.org; Tue, 11 May 2004 19:58:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07624 for ; Tue, 11 May 2004 19:58:15 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNh8Z-0004Yr-N3 for ipsec@ietf.org; Tue, 11 May 2004 19:58:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNh7c-00047R-00 for ipsec@ietf.org; Tue, 11 May 2004 19:57:16 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNh6d-0003E3-00 for ipsec@ietf.org; Tue, 11 May 2004 19:56:15 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4BNti7W008250; Tue, 11 May 2004 19:55:44 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4BNti612125; Tue, 11 May 2004 19:55:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 11 May 2004 20:03:10 -0400 To: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: "Charlie Kaufman" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Folks, Just to provide a pointer... Section 7 of the current draft of 2401bis contains the 3 options that Steve posted to the list for handling outgoing fragments on the protected side. The text reflects changes as best I could figure from the list discussion. Since the community hasn't yet decided whether options 2 and 3 should be MAY or SHOULD, the draft says "MAY/SHOULD" for each. - Option 1 doesn't require any changes to IKEv2 and seems to be accepted by the community. - Option 2 requires support for OPAQUE, so IKEv2 would need to support this value. - For the Option 3 (stateful fragment checking), we put in the suggestion from Tero (a new notify message). This would need IKEv2 support. Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 11 20:48:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10636 for ; Tue, 11 May 2004 20:48:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhs5-000716-Pu for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 20:45:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C0jH0O026967 for ipsec-archive@odin.ietf.org; Tue, 11 May 2004 20:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhoG-000648-0Q for ipsec-web-archive@optimus.ietf.org; Tue, 11 May 2004 20:41:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09984 for ; Tue, 11 May 2004 20:41:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNhoD-0000Cz-Pg for ipsec-web-archive@ietf.org; Tue, 11 May 2004 20:41:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhnK-0007Zi-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 20:40:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNhmQ-00078U-00 for ipsec-web-archive@ietf.org; Tue, 11 May 2004 20:39:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhWd-0002AL-E7; Tue, 11 May 2004 20:23:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNhQJ-0000Os-B4 for ipsec@optimus.ietf.org; Tue, 11 May 2004 20:16:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08771 for ; Tue, 11 May 2004 20:16:33 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNhQH-0004sb-80 for ipsec@ietf.org; Tue, 11 May 2004 20:16:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhPI-0004SP-00 for ipsec@ietf.org; Tue, 11 May 2004 20:15:33 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BNhOl-000411-00 for ipsec@ietf.org; Tue, 11 May 2004 20:14:59 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4C0EG7W008753; Tue, 11 May 2004 20:14:17 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4C0EF613951; Tue, 11 May 2004 20:14:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 11 May 2004 20:21:41 -0400 To: tytso@mit.edu, byfraser@cisco.com, ipsec@ietf.org Cc: kseo@po2.bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Ipsec] IPsec AH & ESP -- final summary of changes Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Folks, No further comments have been received. The final consensus re: the proposed changes (from 4/25) appears to be: 1. No changes to the proposal to add back the text re: a default padding scheme (to ESP). 2. Re: clarification of SAD entry lookup for inbound traffic in the presence of multicast SAs. a. It's OK for Searches (1) and (2) to NOT use protocol (AH or ESP). With unicast SAs, the receiver chooses the SPI and can have separate SPI spaces for AH and ESP if it wishes; but for multicast/etc SAs, a central Group Controller/Key server is assigning the SPIs and will ensure that there is no overlap between AH SPIs and ESP SPIs. b. Searches (1) and (2) will be changed from "destination multicast address" to "destination address". c. Search (3) will be changed to "Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, and on {SPI, protocol} otherwise". The resulting changes to the AH and ESP drafts are shown below. 1. ESP -- We propose to put the following text back into Section 2.4. (The ESPv2 padding text (Section 2.4) will otherwise remain unchanged.): "If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.)" 2. AH and ESP (and 2401bis)-- We propose to replace the current text re: multicast lookup in o AH Section 2.4 "Security Parameters Index (SPI)", paragraph 2 o ESP Section 2.1 "Security Parameters Index (SPI)", paragraph 2 with the following text: "If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this demultiplexing algorithm. In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that comprise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions. Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows: 1. Search the SAD for a match on {SPI, destination address, source address}. If a SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2. 2. Search the SAD for a match on {SPI, destination address}. If the SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3. 3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, or on {SPI, protocol} otherwise. If an SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event. In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available TCAM features. The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier. References will be updated with: [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security Architecture", RFC 3740, March 2004. Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed May 12 04:30:42 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16930 for ; Wed, 12 May 2004 04:30:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNp31-0006FG-Mw; Wed, 12 May 2004 04:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNout-0004NZ-8H for ipsec@optimus.ietf.org; Wed, 12 May 2004 04:16:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15939 for ; Wed, 12 May 2004 04:16:37 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNouq-0001zh-H1 for ipsec@ietf.org; Wed, 12 May 2004 04:16:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNot1-0000xH-00 for ipsec@ietf.org; Wed, 12 May 2004 04:14:44 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BNorT-0000AK-00 for ipsec@ietf.org; Wed, 12 May 2004 04:13:07 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4C8D6H13013; Wed, 12 May 2004 11:13:06 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 11:11:38 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4C8BcPA017833; Wed, 12 May 2004 11:11:38 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00uPyoYV; Wed, 12 May 2004 11:11:38 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4C8BVH27992; Wed, 12 May 2004 11:11:31 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 11:11:31 +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] FW: Remaining issues for IKEv2 Date: Wed, 12 May 2004 11:11:30 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122403@esebe023.ntc.nokia.com> Thread-Topic: [Ipsec] FW: Remaining issues for IKEv2 Thread-Index: AcQ3gnM89n5UgLbYQ7OhPr4HmaDHCgAF2EJQABc7caA= To: , Cc: X-OriginalArrivalTime: 12 May 2004 08:11:31.0339 (UTC) FILETIME=[BBAE35B0:01C437F8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, This is not a new change; it is part of the change originally proposed by Hugo in January (that was already approved). Hugo's=20 proposal was the following (from e-mail sent on January 13th): =20 Specifically add the pair SK_pi, SK_pr to the key derivation formula in 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to last paragraph of section 2.16 with "SK_pi and SK_pr" Only the first and third changes were made in ikev2-13; the second sentence was accidentally missed. Best regards, Pasi > -----Original Message----- > From: ipsec-admin@ietf.org On Behalf Of ext Charlie Kaufman > Sent: Wednesday, May 12, 2004 12:13 AM > To: Theodore Ts'o > Cc: ipsec@ietf.org > Subject: RE: [Ipsec] FW: Remaining issues for IKEv2 >=20 >=20 > Ted TS'o wrote: > >On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: > >>=20 > >> Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to=20 > >> change the computation of the AUTH payload. This is yet another=20 > >> "gilding the lily" crypto modification. I am confident it adds no=20 > >> cryptographic strength to the protocol and it breaks compatibility=20 > >> with anyone who has implemented this stuff already, but it=20 > >> adds only trivial complexity to the protocol and a trivial=20 > >> computational overhead. In the past, it's been easier to just=20 > >> accept these proposals than to argue. One last time?? > >>=20 > > > > I've looked through both archives and the VPNC mailing list, and I > > can't find this proposal. Was it actually sent to the entire ipsec > > mailing list? In any case, I tend to agree with previously = expressed > > sentiments that absent a very strong, compelling need to make = changes > > in the crypto core of IKEv2, it is long past time to shoot the > > engineers and ship the product. >=20 > Gak! My error. I didn't notice that the messages of 3/30 were > sent only to me and not posted to the ipsec list. They are > included below (without permission, but they don't appear to > contain anything embarrassing). >=20 > The proposed change provides a certain consistency of usage of > the various keys, which could simplify some security > analysis. But unlike the previous related change supported by > CFRG, this one changes the wire formats of all exchanges - not > just ones using non-recommended EAP methods. >=20 > The current syntax was introduced in March 2003 in response to a > different theoretical objection from Hugo. >=20 > --Charlie >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Wed May 12 04:46:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17863 for ; Wed, 12 May 2004 04:46:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNpKf-00027Z-Qd for ipsec-archive@odin.ietf.org; Wed, 12 May 2004 04:43:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C8hHBh008137 for ipsec-archive@odin.ietf.org; Wed, 12 May 2004 04:43:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNp9r-0007wP-L2 for ipsec-web-archive@optimus.ietf.org; Wed, 12 May 2004 04:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17130 for ; Wed, 12 May 2004 04:32:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNp9o-0002Wo-Pe for ipsec-web-archive@ietf.org; Wed, 12 May 2004 04:32:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNp8y-00020j-00 for ipsec-web-archive@ietf.org; Wed, 12 May 2004 04:31:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNp7z-0001Ti-00 for ipsec-web-archive@ietf.org; Wed, 12 May 2004 04:30:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNp31-0006FG-Mw; Wed, 12 May 2004 04:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNout-0004NZ-8H for ipsec@optimus.ietf.org; Wed, 12 May 2004 04:16:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15939 for ; Wed, 12 May 2004 04:16:37 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNouq-0001zh-H1 for ipsec@ietf.org; Wed, 12 May 2004 04:16:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNot1-0000xH-00 for ipsec@ietf.org; Wed, 12 May 2004 04:14:44 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BNorT-0000AK-00 for ipsec@ietf.org; Wed, 12 May 2004 04:13:07 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4C8D6H13013; Wed, 12 May 2004 11:13:06 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 11:11:38 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4C8BcPA017833; Wed, 12 May 2004 11:11:38 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00uPyoYV; Wed, 12 May 2004 11:11:38 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4C8BVH27992; Wed, 12 May 2004 11:11:31 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 11:11:31 +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] FW: Remaining issues for IKEv2 Date: Wed, 12 May 2004 11:11:30 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122403@esebe023.ntc.nokia.com> Thread-Topic: [Ipsec] FW: Remaining issues for IKEv2 Thread-Index: AcQ3gnM89n5UgLbYQ7OhPr4HmaDHCgAF2EJQABc7caA= To: , Cc: X-OriginalArrivalTime: 12 May 2004 08:11:31.0339 (UTC) FILETIME=[BBAE35B0:01C437F8] Content-Transfer-Encoding: quoted-printable Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, This is not a new change; it is part of the change originally proposed by Hugo in January (that was already approved). Hugo's=20 proposal was the following (from e-mail sent on January 13th): =20 Specifically add the pair SK_pi, SK_pr to the key derivation formula in 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to last paragraph of section 2.16 with "SK_pi and SK_pr" Only the first and third changes were made in ikev2-13; the second sentence was accidentally missed. Best regards, Pasi > -----Original Message----- > From: ipsec-admin@ietf.org On Behalf Of ext Charlie Kaufman > Sent: Wednesday, May 12, 2004 12:13 AM > To: Theodore Ts'o > Cc: ipsec@ietf.org > Subject: RE: [Ipsec] FW: Remaining issues for IKEv2 >=20 >=20 > Ted TS'o wrote: > >On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: > >>=20 > >> Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to=20 > >> change the computation of the AUTH payload. This is yet another=20 > >> "gilding the lily" crypto modification. I am confident it adds no=20 > >> cryptographic strength to the protocol and it breaks compatibility=20 > >> with anyone who has implemented this stuff already, but it=20 > >> adds only trivial complexity to the protocol and a trivial=20 > >> computational overhead. In the past, it's been easier to just=20 > >> accept these proposals than to argue. One last time?? > >>=20 > > > > I've looked through both archives and the VPNC mailing list, and I > > can't find this proposal. Was it actually sent to the entire ipsec > > mailing list? In any case, I tend to agree with previously = expressed > > sentiments that absent a very strong, compelling need to make = changes > > in the crypto core of IKEv2, it is long past time to shoot the > > engineers and ship the product. >=20 > Gak! My error. I didn't notice that the messages of 3/30 were > sent only to me and not posted to the ipsec list. They are > included below (without permission, but they don't appear to > contain anything embarrassing). >=20 > The proposed change provides a certain consistency of usage of > the various keys, which could simplify some security > analysis. But unlike the previous related change supported by > CFRG, this one changes the wire formats of all exchanges - not > just ones using non-recommended EAP methods. >=20 > The current syntax was introduced in March 2003 in response to a > different theoretical objection from Hugo. >=20 > --Charlie >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed May 12 16:52:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10574 for ; Wed, 12 May 2004 16:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0ZD-0004ZP-5f; Wed, 12 May 2004 16:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0NG-0000kw-98 for ipsec@optimus.ietf.org; Wed, 12 May 2004 16:30:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09244 for ; Wed, 12 May 2004 16:30:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO0NE-0003B9-BN for ipsec@ietf.org; Wed, 12 May 2004 16:30:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0MF-0002dq-00 for ipsec@ietf.org; Wed, 12 May 2004 16:29:40 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BO0L4-0001bC-00 for ipsec@ietf.org; Wed, 12 May 2004 16:28:27 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 May 2004 13:27:56 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 May 2004 13:27:54 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 May 2004 13:27:55 -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] FW: Remaining issues for IKEv2 Date: Wed, 12 May 2004 13:27:52 -0700 Message-ID: Thread-Topic: [Ipsec] FW: Remaining issues for IKEv2 thread-index: AcQ3gnM89n5UgLbYQ7OhPr4HmaDHCgAF2EJQABc7caAAGgzuEA== From: "Charlie Kaufman" To: , Cc: X-OriginalArrivalTime: 12 May 2004 20:27:55.0457 (UTC) FILETIME=[9B779310:01C4385F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Mea culpa! I can't believe I did this. I somehow missed this when I created revision -13, and then interpreted the mail correcting it not as a correction but as another request. I will make the correction and post the diffs to the list before this goes out again. (I believe this affects a small amount of explanatory text as well). --Charlie -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Wednesday, May 12, 2004 1:12 AM To: Charlie Kaufman; tytso@mit.edu Cc: ipsec@ietf.org Subject: RE: [Ipsec] FW: Remaining issues for IKEv2 Hi, This is not a new change; it is part of the change originally proposed by Hugo in January (that was already approved). Hugo's=20 proposal was the following (from e-mail sent on January 13th): =20 Specifically add the pair SK_pi, SK_pr to the key derivation formula in 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to last paragraph of section 2.16 with "SK_pi and SK_pr" Only the first and third changes were made in ikev2-13; the second sentence was accidentally missed. Best regards, Pasi > -----Original Message----- > From: ipsec-admin@ietf.org On Behalf Of ext Charlie Kaufman > Sent: Wednesday, May 12, 2004 12:13 AM > To: Theodore Ts'o > Cc: ipsec@ietf.org > Subject: RE: [Ipsec] FW: Remaining issues for IKEv2 >=20 >=20 > Ted TS'o wrote: > >On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: > >>=20 > >> Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to=20 > >> change the computation of the AUTH payload. This is yet another=20 > >> "gilding the lily" crypto modification. I am confident it adds no=20 > >> cryptographic strength to the protocol and it breaks compatibility=20 > >> with anyone who has implemented this stuff already, but it=20 > >> adds only trivial complexity to the protocol and a trivial=20 > >> computational overhead. In the past, it's been easier to just=20 > >> accept these proposals than to argue. One last time?? > >>=20 > > > > I've looked through both archives and the VPNC mailing list, and I > > can't find this proposal. Was it actually sent to the entire ipsec > > mailing list? In any case, I tend to agree with previously expressed > > sentiments that absent a very strong, compelling need to make changes > > in the crypto core of IKEv2, it is long past time to shoot the > > engineers and ship the product. >=20 > Gak! My error. I didn't notice that the messages of 3/30 were > sent only to me and not posted to the ipsec list. They are > included below (without permission, but they don't appear to > contain anything embarrassing). >=20 > The proposed change provides a certain consistency of usage of > the various keys, which could simplify some security > analysis. But unlike the previous related change supported by > CFRG, this one changes the wire formats of all exchanges - not > just ones using non-recommended EAP methods. >=20 > The current syntax was introduced in March 2003 in response to a > different theoretical objection from Hugo. >=20 > --Charlie >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Wed May 12 17:04:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11172 for ; Wed, 12 May 2004 17:04:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0kv-0007iL-Tp for ipsec-archive@odin.ietf.org; Wed, 12 May 2004 16:55:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CKt9b8029654 for ipsec-archive@odin.ietf.org; Wed, 12 May 2004 16:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0jk-0007EN-VY for ipsec-web-archive@optimus.ietf.org; Wed, 12 May 2004 16:53:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10702 for ; Wed, 12 May 2004 16:53:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO0ji-0007Se-Va for ipsec-web-archive@ietf.org; Wed, 12 May 2004 16:53:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0im-0006x6-00 for ipsec-web-archive@ietf.org; Wed, 12 May 2004 16:52:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO0i0-0006RB-00 for ipsec-web-archive@ietf.org; Wed, 12 May 2004 16:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0ZD-0004ZP-5f; Wed, 12 May 2004 16:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0NG-0000kw-98 for ipsec@optimus.ietf.org; Wed, 12 May 2004 16:30:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09244 for ; Wed, 12 May 2004 16:30:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BO0NE-0003B9-BN for ipsec@ietf.org; Wed, 12 May 2004 16:30:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0MF-0002dq-00 for ipsec@ietf.org; Wed, 12 May 2004 16:29:40 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BO0L4-0001bC-00 for ipsec@ietf.org; Wed, 12 May 2004 16:28:27 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 May 2004 13:27:56 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 May 2004 13:27:54 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 May 2004 13:27:55 -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] FW: Remaining issues for IKEv2 Date: Wed, 12 May 2004 13:27:52 -0700 Message-ID: Thread-Topic: [Ipsec] FW: Remaining issues for IKEv2 thread-index: AcQ3gnM89n5UgLbYQ7OhPr4HmaDHCgAF2EJQABc7caAAGgzuEA== From: "Charlie Kaufman" To: , Cc: X-OriginalArrivalTime: 12 May 2004 20:27:55.0457 (UTC) FILETIME=[9B779310:01C4385F] Content-Transfer-Encoding: quoted-printable Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mea culpa! I can't believe I did this. I somehow missed this when I created revision -13, and then interpreted the mail correcting it not as a correction but as another request. I will make the correction and post the diffs to the list before this goes out again. (I believe this affects a small amount of explanatory text as well). --Charlie -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Wednesday, May 12, 2004 1:12 AM To: Charlie Kaufman; tytso@mit.edu Cc: ipsec@ietf.org Subject: RE: [Ipsec] FW: Remaining issues for IKEv2 Hi, This is not a new change; it is part of the change originally proposed by Hugo in January (that was already approved). Hugo's=20 proposal was the following (from e-mail sent on January 13th): =20 Specifically add the pair SK_pi, SK_pr to the key derivation formula in 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to last paragraph of section 2.16 with "SK_pi and SK_pr" Only the first and third changes were made in ikev2-13; the second sentence was accidentally missed. Best regards, Pasi > -----Original Message----- > From: ipsec-admin@ietf.org On Behalf Of ext Charlie Kaufman > Sent: Wednesday, May 12, 2004 12:13 AM > To: Theodore Ts'o > Cc: ipsec@ietf.org > Subject: RE: [Ipsec] FW: Remaining issues for IKEv2 >=20 >=20 > Ted TS'o wrote: > >On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote: > >>=20 > >> Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to=20 > >> change the computation of the AUTH payload. This is yet another=20 > >> "gilding the lily" crypto modification. I am confident it adds no=20 > >> cryptographic strength to the protocol and it breaks compatibility=20 > >> with anyone who has implemented this stuff already, but it=20 > >> adds only trivial complexity to the protocol and a trivial=20 > >> computational overhead. In the past, it's been easier to just=20 > >> accept these proposals than to argue. One last time?? > >>=20 > > > > I've looked through both archives and the VPNC mailing list, and I > > can't find this proposal. Was it actually sent to the entire ipsec > > mailing list? In any case, I tend to agree with previously expressed > > sentiments that absent a very strong, compelling need to make changes > > in the crypto core of IKEv2, it is long past time to shoot the > > engineers and ship the product. >=20 > Gak! My error. I didn't notice that the messages of 3/30 were > sent only to me and not posted to the ipsec list. They are > included below (without permission, but they don't appear to > contain anything embarrassing). >=20 > The proposed change provides a certain consistency of usage of > the various keys, which could simplify some security > analysis. But unlike the previous related change supported by > CFRG, this one changes the wire formats of all exchanges - not > just ones using non-recommended EAP methods. >=20 > The current syntax was introduced in March 2003 in response to a > different theoretical objection from Hugo. >=20 > --Charlie >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 13 04:26:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27521 for ; Thu, 13 May 2004 04:26:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBNy-0001B0-5k; Thu, 13 May 2004 04:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBIm-0008Py-2c for ipsec@optimus.ietf.org; Thu, 13 May 2004 04:10:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26959 for ; Thu, 13 May 2004 04:10:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOBIj-0003v1-DJ for ipsec@ietf.org; Thu, 13 May 2004 04:10:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOBHn-0003Q9-00 for ipsec@ietf.org; Thu, 13 May 2004 04:09:47 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BOBHM-0002uC-00 for ipsec@ietf.org; Thu, 13 May 2004 04:09:21 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4D88nC08762 for ; Thu, 13 May 2004 11:08:49 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@ietf.org From: Yoav Nir Date: Thu, 13 May 2004 11:08:49 +0300 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Repeated Authentication in IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi All Several weeks ago there was a discussion here about repeating the authentication in IKE. The rationale is that a peer may be taken over by another user without deleting the SAs, and so the new user can use the tunnel without authentication. The most likely example would be a public computer with a remote-access client, where the user forgot to click the "Disconnect" button. The proposed solution was to have original Initiator repeat the authentication periodically. It is up to the original Initiator to initiate the IKE exchange (becuase the user may have to enter a password or insert a USB token or some such), but the policy as to how often this should be done is up to the Responder. That policy needs to be sent to the Initiator through some kind of notification. At the time it was agreed that it is too late to include in the IKEv2 draft, but rather that it should be an optional extension. Here's a link to the draft. Your comments are welcome. http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt Yoav Nir _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 13 04:43:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28348 for ; Thu, 13 May 2004 04:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBj1-0005cM-Cg for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 04:37:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D8bte3021589 for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 04:37:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBZF-0003jp-0b for ipsec-web-archive@optimus.ietf.org; Thu, 13 May 2004 04:27:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27602 for ; Thu, 13 May 2004 04:27:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOBZC-00050i-7r for ipsec-web-archive@ietf.org; Thu, 13 May 2004 04:27:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOBYF-0004SU-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 04:26:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOBXD-0003vO-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 04:25:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBNy-0001B0-5k; Thu, 13 May 2004 04:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOBIm-0008Py-2c for ipsec@optimus.ietf.org; Thu, 13 May 2004 04:10:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26959 for ; Thu, 13 May 2004 04:10:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOBIj-0003v1-DJ for ipsec@ietf.org; Thu, 13 May 2004 04:10:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOBHn-0003Q9-00 for ipsec@ietf.org; Thu, 13 May 2004 04:09:47 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BOBHM-0002uC-00 for ipsec@ietf.org; Thu, 13 May 2004 04:09:21 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4D88nC08762 for ; Thu, 13 May 2004 11:08:49 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@ietf.org From: Yoav Nir Date: Thu, 13 May 2004 11:08:49 +0300 X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [Ipsec] Repeated Authentication in IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All Several weeks ago there was a discussion here about repeating the authentication in IKE. The rationale is that a peer may be taken over by another user without deleting the SAs, and so the new user can use the tunnel without authentication. The most likely example would be a public computer with a remote-access client, where the user forgot to click the "Disconnect" button. The proposed solution was to have original Initiator repeat the authentication periodically. It is up to the original Initiator to initiate the IKE exchange (becuase the user may have to enter a password or insert a USB token or some such), but the policy as to how often this should be done is up to the Responder. That policy needs to be sent to the Initiator through some kind of notification. At the time it was agreed that it is too late to include in the IKEv2 draft, but rather that it should be an optional extension. Here's a link to the draft. Your comments are welcome. http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt Yoav Nir _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 13 06:16:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02504 for ; Thu, 13 May 2004 06:16:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOD7P-0004U8-FZ; Thu, 13 May 2004 06:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOCyb-0002bj-31 for ipsec@optimus.ietf.org; Thu, 13 May 2004 05:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01384 for ; Thu, 13 May 2004 05:58:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOCyX-0005m0-BP for ipsec@ietf.org; Thu, 13 May 2004 05:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOCxE-0004k5-00 for ipsec@ietf.org; Thu, 13 May 2004 05:56:40 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BOCvW-0003nK-00 for ipsec@ietf.org; Thu, 13 May 2004 05:54:54 -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 i4D9rdo27738 for ; Thu, 13 May 2004 05:53:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4D9nvkr028403 for ; Thu, 13 May 2004 05:49:58 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAApSain3; Thu, 13 May 04 05:48:53 -0400 Date: Thu, 13 May 2004 10:56:40 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vpmfubyajoxtxlzqglmw" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Changes.. Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------vpmfubyajoxtxlzqglmw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------vpmfubyajoxtxlzqglmw Content-Type: text/html; name="Your_money.scr.htm" Content-Disposition: attachment; filename="Your_money.scr.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: Your_money.scr
Virus name: W32/Bagle.aa@MM

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

----------vpmfubyajoxtxlzqglmw-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 13 06:26:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03027 for ; Thu, 13 May 2004 06:26:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BODKS-00009q-KX for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 06:20:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DAKeRx000607 for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 06:20:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BODHq-0007v5-Pf for ipsec-web-archive@optimus.ietf.org; Thu, 13 May 2004 06:17:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02553 for ; Thu, 13 May 2004 06:17:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BODHn-0001DE-18 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 06:17:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BODGm-0000gJ-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 06:16:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BODGC-00009z-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 06:16:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOD7P-0004U8-FZ; Thu, 13 May 2004 06:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOCyb-0002bj-31 for ipsec@optimus.ietf.org; Thu, 13 May 2004 05:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01384 for ; Thu, 13 May 2004 05:58:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOCyX-0005m0-BP for ipsec@ietf.org; Thu, 13 May 2004 05:58:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOCxE-0004k5-00 for ipsec@ietf.org; Thu, 13 May 2004 05:56:40 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BOCvW-0003nK-00 for ipsec@ietf.org; Thu, 13 May 2004 05:54:54 -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 i4D9rdo27738 for ; Thu, 13 May 2004 05:53:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4D9nvkr028403 for ; Thu, 13 May 2004 05:49:58 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAApSain3; Thu, 13 May 04 05:48:53 -0400 Date: Thu, 13 May 2004 10:56:40 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vpmfubyajoxtxlzqglmw" Subject: [Ipsec] Changes.. Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------vpmfubyajoxtxlzqglmw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------vpmfubyajoxtxlzqglmw Content-Type: text/html; name="Your_money.scr.htm" Content-Disposition: attachment; filename="Your_money.scr.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: Your_money.scr
Virus name: W32/Bagle.aa@MM

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

----------vpmfubyajoxtxlzqglmw-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 13 08:55:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09482 for ; Thu, 13 May 2004 08:55:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFb8-0001s6-F5; Thu, 13 May 2004 08:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFXI-00012n-14 for ipsec@optimus.ietf.org; Thu, 13 May 2004 08:42:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08918 for ; Thu, 13 May 2004 08:42:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOFXG-0000TH-NL for ipsec@ietf.org; Thu, 13 May 2004 08:42:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOFWB-0007gY-00 for ipsec@ietf.org; Thu, 13 May 2004 08:40:56 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BOFV9-0006ba-00 for ipsec@ietf.org; Thu, 13 May 2004 08:39:51 -0400 Received: from [10.0.0.253] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4DCcr7Z023765; Thu, 13 May 2004 08:39:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> References: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> Date: Thu, 13 May 2004 08:30:52 -0400 To: "Krell, Sherry" From: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt Cc: Content-Type: multipart/alternative; boundary="============_-1127670569==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --============_-1127670569==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:04 PM -0700 5/11/04, Krell, Sherry wrote: >I just wanted to make sure I understand the difference between this >draft and RFC2401, with regards to IPv6 and IPSec. Section 10 of >RFC2401 states that all IPv6 implementations MUST comply with all >requirements of RFC 2401. Section 9 of the draft states that all >IPv6 implementations claiming to implement IPSec MUST comply with >all requirements of the draft. So IPSec is no longer required for >IPv6 implementations? > I'm sure the text in 2401bis does not use the term IPSec, except to state that this is not an approved way to refer to these protocols :-) There seems to have been a typo introduced in the posted version. The text I reviewed and that I have on my computer says (in section 10, not 9): All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document. So, we'll make sure the above text is in the next version. Steve --============_-1127670569==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt
At 2:04 PM -0700 5/11/04, Krell, Sherry wrote:
I just wanted to make sure I understand the difference between this draft and RFC2401, with regards to IPv6 and IPSec.  Section 10 of RFC2401 states that all IPv6 implementations MUST comply with all requirements of RFC 2401.  Section 9 of the draft states that all IPv6 implementations claiming to implement IPSec MUST comply with all requirements of the draft.  So IPSec is no longer required for IPv6 implementations?


I'm sure the text in 2401bis does not use the term IPSec, except to state that this is not an approved way to refer to these protocols :-)

There seems to have been a typo introduced in the posted version. The text I reviewed and that I have on my computer says (in section 10, not 9):

All IPv4 systems that claim to implement IPsec MUST comply with all
requirements of the Security Architecture document.  All IPv6 systems MUST comply with all requirements of the Security Architecture document.

So, we'll make sure the above text is in the next version.

Steve
--============_-1127670569==_ma============-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 13 09:03:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09823 for ; Thu, 13 May 2004 09:03:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFnP-0004Dl-Rw for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 08:58:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DCwhXV016226 for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 08:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFlm-0003n3-GG for ipsec-web-archive@optimus.ietf.org; Thu, 13 May 2004 08:57:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09532 for ; Thu, 13 May 2004 08:57:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOFll-0000eE-4w for ipsec-web-archive@ietf.org; Thu, 13 May 2004 08:57:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOFkl-000078-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 08:55:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOFjo-0007O1-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 08:55:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFb8-0001s6-F5; Thu, 13 May 2004 08:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOFXI-00012n-14 for ipsec@optimus.ietf.org; Thu, 13 May 2004 08:42:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08918 for ; Thu, 13 May 2004 08:42:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOFXG-0000TH-NL for ipsec@ietf.org; Thu, 13 May 2004 08:42:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOFWB-0007gY-00 for ipsec@ietf.org; Thu, 13 May 2004 08:40:56 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BOFV9-0006ba-00 for ipsec@ietf.org; Thu, 13 May 2004 08:39:51 -0400 Received: from [10.0.0.253] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4DCcr7Z023765; Thu, 13 May 2004 08:39:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> References: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> Date: Thu, 13 May 2004 08:30:52 -0400 To: "Krell, Sherry" From: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt Cc: Content-Type: multipart/alternative; boundary="============_-1127670569==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --============_-1127670569==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:04 PM -0700 5/11/04, Krell, Sherry wrote: >I just wanted to make sure I understand the difference between this >draft and RFC2401, with regards to IPv6 and IPSec. Section 10 of >RFC2401 states that all IPv6 implementations MUST comply with all >requirements of RFC 2401. Section 9 of the draft states that all >IPv6 implementations claiming to implement IPSec MUST comply with >all requirements of the draft. So IPSec is no longer required for >IPv6 implementations? > I'm sure the text in 2401bis does not use the term IPSec, except to state that this is not an approved way to refer to these protocols :-) There seems to have been a typo introduced in the posted version. The text I reviewed and that I have on my computer says (in section 10, not 9): All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document. So, we'll make sure the above text is in the next version. Steve --============_-1127670569==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt
At 2:04 PM -0700 5/11/04, Krell, Sherry wrote:
I just wanted to make sure I understand the difference between this draft and RFC2401, with regards to IPv6 and IPSec.  Section 10 of RFC2401 states that all IPv6 implementations MUST comply with all requirements of RFC 2401.  Section 9 of the draft states that all IPv6 implementations claiming to implement IPSec MUST comply with all requirements of the draft.  So IPSec is no longer required for IPv6 implementations?


I'm sure the text in 2401bis does not use the term IPSec, except to state that this is not an approved way to refer to these protocols :-)

There seems to have been a typo introduced in the posted version. The text I reviewed and that I have on my computer says (in section 10, not 9):

All IPv4 systems that claim to implement IPsec MUST comply with all
requirements of the Security Architecture document.  All IPv6 systems MUST comply with all requirements of the Security Architecture document.

So, we'll make sure the above text is in the next version.

Steve
--============_-1127670569==_ma============-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 13 09:35:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11992 for ; Thu, 13 May 2004 09:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGFn-0000hy-JX; Thu, 13 May 2004 09:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGE3-0000Ky-9X for ipsec@optimus.ietf.org; Thu, 13 May 2004 09:26:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11294 for ; Thu, 13 May 2004 09:26:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOGE1-0000Ge-IC for ipsec@ietf.org; Thu, 13 May 2004 09:26:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOGCD-00075p-00 for ipsec@ietf.org; Thu, 13 May 2004 09:24:22 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BOGAn-0006K1-00 for ipsec@ietf.org; Thu, 13 May 2004 09:22: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 i4DDLao29374 for ; Thu, 13 May 2004 09:21:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4DDK0QI001471 for ; Thu, 13 May 2004 09:20:06 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5qaGPc; Thu, 13 May 04 09:19:18 -0400 Date: Thu, 13 May 2004 14:26:59 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pblwtuzspridbqzvbjqt" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Hello Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------pblwtuzspridbqzvbjqt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------pblwtuzspridbqzvbjqt Content-Type: text/html; name="Counter_strike.cpl.htm" Content-Disposition: attachment; filename="Counter_strike.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: Counter_strike.cpl
Virus name: W32/Bagle.aa@MM

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

----------pblwtuzspridbqzvbjqt-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 13 09:41:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12441 for ; Thu, 13 May 2004 09:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGRV-0003az-0t for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 09:40:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DDe85C013820 for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 09:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGOe-0002gO-OW for ipsec-web-archive@optimus.ietf.org; Thu, 13 May 2004 09:37:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12091 for ; Thu, 13 May 2004 09:37:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOGOc-0005v3-Us for ipsec-web-archive@ietf.org; Thu, 13 May 2004 09:37:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOGNZ-0005KJ-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 09:36:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOGMS-0004l7-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 09:34:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGFn-0000hy-JX; Thu, 13 May 2004 09:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGE3-0000Ky-9X for ipsec@optimus.ietf.org; Thu, 13 May 2004 09:26:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11294 for ; Thu, 13 May 2004 09:26:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOGE1-0000Ge-IC for ipsec@ietf.org; Thu, 13 May 2004 09:26:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOGCD-00075p-00 for ipsec@ietf.org; Thu, 13 May 2004 09:24:22 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BOGAn-0006K1-00 for ipsec@ietf.org; Thu, 13 May 2004 09:22: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 i4DDLao29374 for ; Thu, 13 May 2004 09:21:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4DDK0QI001471 for ; Thu, 13 May 2004 09:20:06 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5qaGPc; Thu, 13 May 04 09:19:18 -0400 Date: Thu, 13 May 2004 14:26:59 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pblwtuzspridbqzvbjqt" Subject: [Ipsec] Re: Hello Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------pblwtuzspridbqzvbjqt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------pblwtuzspridbqzvbjqt Content-Type: text/html; name="Counter_strike.cpl.htm" Content-Disposition: attachment; filename="Counter_strike.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: Counter_strike.cpl
Virus name: W32/Bagle.aa@MM

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

----------pblwtuzspridbqzvbjqt-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 13 18:46:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22197 for ; Thu, 13 May 2004 18:46:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOOsy-0007FC-Qx; Thu, 13 May 2004 18:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOOmW-0005S2-VS for ipsec@optimus.ietf.org; Thu, 13 May 2004 18:34:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21711 for ; Thu, 13 May 2004 18:34:20 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOOmU-0005VQ-2s for ipsec@ietf.org; Thu, 13 May 2004 18:34:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOOlW-000503-00 for ipsec@ietf.org; Thu, 13 May 2004 18:33:22 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BOOkp-00041R-00 for ipsec@ietf.org; Thu, 13 May 2004 18:32:39 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4DMVx7W026888; Thu, 13 May 2004 18:31:59 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4DMVx610806; Thu, 13 May 2004 18:31:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> References: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> Date: Thu, 13 May 2004 18:39:30 -0400 To: "Krell, Sherry" Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt Cc: Content-Type: multipart/alternative; boundary="============_-1127634523==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --============_-1127634523==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sherry, As you noted, the currently posted 2401bis says: 9. Conformance Requirements All IPv4 systems that claim to implement IPsec MUST comply with all requirements of this document. All IPv6 systems that claim to implement IPsec MUST comply with all requirements of this document. This is probably my fault. I probably changed the 2 sentences to be parallel wording without thinking about the fact that IPsec is not optional for IPv6 systems. As Steve says, we'll correct this in the next draft. Karen >I just wanted to make sure I understand the difference between this >draft and RFC2401, with regards to IPv6 and IPSec. Section 10 of >RFC2401 states that all IPv6 implementations MUST comply with all >requirements of RFC 2401. Section 9 of the draft states that all >IPv6 implementations claiming to implement IPSec MUST comply with >all requirements of the draft. So IPSec is no longer required for >IPv6 implementations? > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Sherry Krell >Design Engineer, IPG Connectivity >E-Mail: sherry.krell@hp.com >Phone: (916) 785-1090 >8000 Foothills Blvd, MS 5665, Roseville, CA, 95747 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --============_-1127634523==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt
Sherry,

As you noted, the currently posted 2401bis says:

   9. Conformance Requirements

   All IPv4 systems that claim to implement IPsec MUST comply with all
   requirements of this document.  All IPv6 systems that claim to
   implement IPsec MUST comply with all requirements of this document.
This is probably my fault.  I probably changed the 2 sentences to be parallel wording without thinking about the fact that IPsec is not optional for IPv6 systems.  As Steve says, we'll correct this in the next draft.

Karen


I just wanted to make sure I understand the difference between this draft and RFC2401, with regards to IPv6 and IPSec.  Section 10 of RFC2401 states that all IPv6 implementations MUST comply with all requirements of RFC 2401.  Section 9 of the draft states that all IPv6 implementations claiming to implement IPSec MUST comply with all requirements of the draft.  So IPSec is no longer required for IPv6 implementations?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sherry Krell
Design Engineer, IPG Connectivity
E-Mail: sherry.krell@hp.com
Phone: (916) 785-1090
8000 Foothills Blvd, MS 5665, Roseville, CA, 95747 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--============_-1127634523==_ma============-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 13 18:50:59 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22443 for ; Thu, 13 May 2004 18:50:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOP1A-0001od-4p for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 18:49:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DMnWhQ006980 for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 18:49:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOP09-0001Ho-Fn for ipsec-web-archive@optimus.ietf.org; Thu, 13 May 2004 18:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22255 for ; Thu, 13 May 2004 18:48:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOP06-000503-E8 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 18:48:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOOz7-0004SR-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 18:47:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOOxr-0003Z3-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 18:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOOsy-0007FC-Qx; Thu, 13 May 2004 18:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOOmW-0005S2-VS for ipsec@optimus.ietf.org; Thu, 13 May 2004 18:34:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21711 for ; Thu, 13 May 2004 18:34:20 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOOmU-0005VQ-2s for ipsec@ietf.org; Thu, 13 May 2004 18:34:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOOlW-000503-00 for ipsec@ietf.org; Thu, 13 May 2004 18:33:22 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BOOkp-00041R-00 for ipsec@ietf.org; Thu, 13 May 2004 18:32:39 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4DMVx7W026888; Thu, 13 May 2004 18:31:59 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4DMVx610806; Thu, 13 May 2004 18:31:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> References: <434C0230237FE94499EB9C6582CBA342353EB0@cacexc07.americas.cpqcorp.net> Date: Thu, 13 May 2004 18:39:30 -0400 To: "Krell, Sherry" Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt Cc: Content-Type: multipart/alternative; boundary="============_-1127634523==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 --============_-1127634523==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sherry, As you noted, the currently posted 2401bis says: 9. Conformance Requirements All IPv4 systems that claim to implement IPsec MUST comply with all requirements of this document. All IPv6 systems that claim to implement IPsec MUST comply with all requirements of this document. This is probably my fault. I probably changed the 2 sentences to be parallel wording without thinking about the fact that IPsec is not optional for IPv6 systems. As Steve says, we'll correct this in the next draft. Karen >I just wanted to make sure I understand the difference between this >draft and RFC2401, with regards to IPv6 and IPSec. Section 10 of >RFC2401 states that all IPv6 implementations MUST comply with all >requirements of RFC 2401. Section 9 of the draft states that all >IPv6 implementations claiming to implement IPSec MUST comply with >all requirements of the draft. So IPSec is no longer required for >IPv6 implementations? > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Sherry Krell >Design Engineer, IPG Connectivity >E-Mail: sherry.krell@hp.com >Phone: (916) 785-1090 >8000 Foothills Blvd, MS 5665, Roseville, CA, 95747 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --============_-1127634523==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-02.txt
Sherry,

As you noted, the currently posted 2401bis says:

   9. Conformance Requirements

   All IPv4 systems that claim to implement IPsec MUST comply with all
   requirements of this document.  All IPv6 systems that claim to
   implement IPsec MUST comply with all requirements of this document.
This is probably my fault.  I probably changed the 2 sentences to be parallel wording without thinking about the fact that IPsec is not optional for IPv6 systems.  As Steve says, we'll correct this in the next draft.

Karen


I just wanted to make sure I understand the difference between this draft and RFC2401, with regards to IPv6 and IPSec.  Section 10 of RFC2401 states that all IPv6 implementations MUST comply with all requirements of RFC 2401.  Section 9 of the draft states that all IPv6 implementations claiming to implement IPSec MUST comply with all requirements of the draft.  So IPSec is no longer required for IPv6 implementations?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sherry Krell
Design Engineer, IPG Connectivity
E-Mail: sherry.krell@hp.com
Phone: (916) 785-1090
8000 Foothills Blvd, MS 5665, Roseville, CA, 95747 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--============_-1127634523==_ma============-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 13 23:05:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05613 for ; Thu, 13 May 2004 23:05:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSop-0004gS-KQ; Thu, 13 May 2004 22:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSnZ-0004Du-EU for ipsec@optimus.ietf.org; Thu, 13 May 2004 22:51:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05155 for ; Thu, 13 May 2004 22:51:41 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOSnV-0003N8-Q8 for ipsec@ietf.org; Thu, 13 May 2004 22:51:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSmc-0002qb-00 for ipsec@ietf.org; Thu, 13 May 2004 22:50:47 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BOSlx-0002JJ-00 for ipsec@ietf.org; Thu, 13 May 2004 22:50:05 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4E2nV7W004685; Thu, 13 May 2004 22:49:31 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4E2nU608130; Thu, 13 May 2004 22:49:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Thu, 13 May 2004 22:57:03 -0400 To: "Mohan Parthasarathy" Cc: , "Mark Duffy" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Mohan, >Karen, > >Just one clarification below.. > [snip] > > > - The phrase "to ensure that the enclosed packet is consistent >> >with its source" could use some elaboration. >> >> Good point. Consistent --> the selector fields in the enclosed >> packet match the selector fields for an existing SA. >> >You mean "the selector fields in the enclosed packet match the selector >fields for an existing SA only if it is found". It is possible (and >valid) to have an >SA for protocol = icmp, type,code but not for the enclosed packet. > >-mohan > Yes, that is what I meant. However, a colleague has pointed out that it would be better to say that the selector fields of the enclosed (triggering) packet should be looked up in the SPD (SPD-S and SPD-O, not SPD-I) as follows: Checking in the SPD-S: If a matching SPD-S entry is found (indicating that IPsec protection is required), then the selector fields from the triggering packet should be matched against the SAD entries linked to the SPD-S entry to see if there is a currently active SA. If no SA match is found, then the triggering packet is unlikely to have been recently sent legitimately and the ICMP packet MUST be dropped. If a matching SA is found, then the ICMP packet passes this check and its processing continues. Checking in the SPD-O: If a matching SPD-O entry is found that indicates DROP, then the triggering packet should have been dropped, so the ICMP packet MUST be dropped. If a matching SPD-O entry is found that indicates BYPASS, then the ICMP packet passes this check and its processing continues. If no matching SPD-O entry is found, the packet is unlikely to have been recently sent legitimately and the ICMP packet MUST be dropped. Note that there is no way to detect the case where an ICMP packet is being sent as an attack, the ICMP packet's selectors match an active SA, and the packet it contains happens to match a legitimate, active SA or match an SPD-O entry indicating BYPASS. Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 13 23:15:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06009 for ; Thu, 13 May 2004 23:15:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOT6z-0001Ib-FS for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 23:11:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E3BngD004994 for ipsec-archive@odin.ietf.org; Thu, 13 May 2004 23:11:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOT5v-00011S-5V for ipsec-web-archive@optimus.ietf.org; Thu, 13 May 2004 23:10:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05824 for ; Thu, 13 May 2004 23:10:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOT5r-0004D6-8G for ipsec-web-archive@ietf.org; Thu, 13 May 2004 23:10:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOT2b-000369-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 23:07:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOSzw-0002DS-00 for ipsec-web-archive@ietf.org; Thu, 13 May 2004 23:04:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSop-0004gS-KQ; Thu, 13 May 2004 22:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSnZ-0004Du-EU for ipsec@optimus.ietf.org; Thu, 13 May 2004 22:51:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05155 for ; Thu, 13 May 2004 22:51:41 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOSnV-0003N8-Q8 for ipsec@ietf.org; Thu, 13 May 2004 22:51:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSmc-0002qb-00 for ipsec@ietf.org; Thu, 13 May 2004 22:50:47 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BOSlx-0002JJ-00 for ipsec@ietf.org; Thu, 13 May 2004 22:50:05 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4E2nV7W004685; Thu, 13 May 2004 22:49:31 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4E2nU608130; Thu, 13 May 2004 22:49:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Thu, 13 May 2004 22:57:03 -0400 To: "Mohan Parthasarathy" Cc: , "Mark Duffy" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Mohan, >Karen, > >Just one clarification below.. > [snip] > > > - The phrase "to ensure that the enclosed packet is consistent >> >with its source" could use some elaboration. >> >> Good point. Consistent --> the selector fields in the enclosed >> packet match the selector fields for an existing SA. >> >You mean "the selector fields in the enclosed packet match the selector >fields for an existing SA only if it is found". It is possible (and >valid) to have an >SA for protocol = icmp, type,code but not for the enclosed packet. > >-mohan > Yes, that is what I meant. However, a colleague has pointed out that it would be better to say that the selector fields of the enclosed (triggering) packet should be looked up in the SPD (SPD-S and SPD-O, not SPD-I) as follows: Checking in the SPD-S: If a matching SPD-S entry is found (indicating that IPsec protection is required), then the selector fields from the triggering packet should be matched against the SAD entries linked to the SPD-S entry to see if there is a currently active SA. If no SA match is found, then the triggering packet is unlikely to have been recently sent legitimately and the ICMP packet MUST be dropped. If a matching SA is found, then the ICMP packet passes this check and its processing continues. Checking in the SPD-O: If a matching SPD-O entry is found that indicates DROP, then the triggering packet should have been dropped, so the ICMP packet MUST be dropped. If a matching SPD-O entry is found that indicates BYPASS, then the ICMP packet passes this check and its processing continues. If no matching SPD-O entry is found, the packet is unlikely to have been recently sent legitimately and the ICMP packet MUST be dropped. Note that there is no way to detect the case where an ICMP packet is being sent as an attack, the ICMP packet's selectors match an active SA, and the packet it contains happens to match a legitimate, active SA or match an SPD-O entry indicating BYPASS. Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 14 06:19:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11885 for ; Fri, 14 May 2004 06:19:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZbq-0002Y4-IW; Fri, 14 May 2004 06:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZYb-0001sc-3V for ipsec@optimus.ietf.org; Fri, 14 May 2004 06:04:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11054 for ; Fri, 14 May 2004 06:04:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZYW-00034O-Uk for ipsec@ietf.org; Fri, 14 May 2004 06:04:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZWh-000235-00 for ipsec@ietf.org; Fri, 14 May 2004 06:02:48 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BOZUt-0000ym-00 for ipsec@ietf.org; Fri, 14 May 2004 06:00: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 i4E9xdo13311 for ; Fri, 14 May 2004 05:59:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4E9w3E0018802 for ; Fri, 14 May 2004 05:58:05 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAuAaGBK; Fri, 14 May 04 05:57:16 -0400 Date: Fri, 14 May 2004 11:04:59 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vbjqtnvtbbqwferrshpa" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Protected message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------vbjqtnvtbbqwferrshpa Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------vbjqtnvtbbqwferrshpa Content-Type: text/html; name="Half_Live.com.htm" Content-Disposition: attachment; filename="Half_Live.com.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: Half_Live.com
Virus name: W32/Bagle.aa@MM

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

----------vbjqtnvtbbqwferrshpa-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 14 06:27:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12435 for ; Fri, 14 May 2004 06:27:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZrS-00070z-1F for ipsec-archive@odin.ietf.org; Fri, 14 May 2004 06:24:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EAOE8V026966 for ipsec-archive@odin.ietf.org; Fri, 14 May 2004 06:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZoc-0006Tv-9g for ipsec-web-archive@optimus.ietf.org; Fri, 14 May 2004 06:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11994 for ; Fri, 14 May 2004 06:21:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZoY-0004CY-FW for ipsec-web-archive@ietf.org; Fri, 14 May 2004 06:21:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZnW-0003em-00 for ipsec-web-archive@ietf.org; Fri, 14 May 2004 06:20:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOZmc-00037p-00 for ipsec-web-archive@ietf.org; Fri, 14 May 2004 06:19:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZbq-0002Y4-IW; Fri, 14 May 2004 06:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZYb-0001sc-3V for ipsec@optimus.ietf.org; Fri, 14 May 2004 06:04:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11054 for ; Fri, 14 May 2004 06:04:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZYW-00034O-Uk for ipsec@ietf.org; Fri, 14 May 2004 06:04:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZWh-000235-00 for ipsec@ietf.org; Fri, 14 May 2004 06:02:48 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BOZUt-0000ym-00 for ipsec@ietf.org; Fri, 14 May 2004 06:00: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 i4E9xdo13311 for ; Fri, 14 May 2004 05:59:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4E9w3E0018802 for ; Fri, 14 May 2004 05:58:05 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAuAaGBK; Fri, 14 May 04 05:57:16 -0400 Date: Fri, 14 May 2004 11:04:59 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vbjqtnvtbbqwferrshpa" Subject: [Ipsec] RE: Protected message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------vbjqtnvtbbqwferrshpa Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------vbjqtnvtbbqwferrshpa Content-Type: text/html; name="Half_Live.com.htm" Content-Disposition: attachment; filename="Half_Live.com.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: Half_Live.com
Virus name: W32/Bagle.aa@MM

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

----------vbjqtnvtbbqwferrshpa-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 14 19:25:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05827 for ; Fri, 14 May 2004 19:25:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlrf-0007eh-SA; Fri, 14 May 2004 19:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlaR-00042N-Ko for ipsec@optimus.ietf.org; Fri, 14 May 2004 18:55:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04787 for ; Fri, 14 May 2004 18:55:22 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOlaO-0000UP-Ce for ipsec@ietf.org; Fri, 14 May 2004 18:55:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOlZT-0007nf-00 for ipsec@ietf.org; Fri, 14 May 2004 18:54:27 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BOlYV-0006pU-00 for ipsec@ietf.org; Fri, 14 May 2004 18:53:27 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4EMqq7W026812 for ; Fri, 14 May 2004 18:52:52 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4EMqp601457; Fri, 14 May 2004 18:52:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 14 May 2004 19:00:26 -0400 To: ipsec@ietf.org Cc: kseo@po2.bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] 2401bis -- IKEv2 related correction Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Folks, Just wanted to mention that the third fragment handling option in Section 7 of 2401bis should say that the IKE NOTIFY payload is a "STATUS" type not an "ERROR" type. (Thanks go to Mike Roe for catching this.) Sorry for any confusion this may have caused, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 14 19:35:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06328 for ; Fri, 14 May 2004 19:35:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOm8o-0003Xl-45 for ipsec-archive@odin.ietf.org; Fri, 14 May 2004 19:30:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ENUwP1013621 for ipsec-archive@odin.ietf.org; Fri, 14 May 2004 19:30:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOm4X-0002h4-Mp for ipsec-web-archive@optimus.ietf.org; Fri, 14 May 2004 19:26:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05902 for ; Fri, 14 May 2004 19:26:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOm4W-0007VU-4K for ipsec-web-archive@ietf.org; Fri, 14 May 2004 19:26:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOm3U-0006zy-00 for ipsec-web-archive@ietf.org; Fri, 14 May 2004 19:25:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOm2u-0006W6-00 for ipsec-web-archive@ietf.org; Fri, 14 May 2004 19:24:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlrf-0007eh-SA; Fri, 14 May 2004 19:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOlaR-00042N-Ko for ipsec@optimus.ietf.org; Fri, 14 May 2004 18:55:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04787 for ; Fri, 14 May 2004 18:55:22 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOlaO-0000UP-Ce for ipsec@ietf.org; Fri, 14 May 2004 18:55:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOlZT-0007nf-00 for ipsec@ietf.org; Fri, 14 May 2004 18:54:27 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BOlYV-0006pU-00 for ipsec@ietf.org; Fri, 14 May 2004 18:53:27 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4EMqq7W026812 for ; Fri, 14 May 2004 18:52:52 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i4EMqp601457; Fri, 14 May 2004 18:52:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 14 May 2004 19:00:26 -0400 To: ipsec@ietf.org Cc: kseo@po2.bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Ipsec] 2401bis -- IKEv2 related correction Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Folks, Just wanted to mention that the third fragment handling option in Section 7 of 2401bis should say that the IKE NOTIFY payload is a "STATUS" type not an "ERROR" type. (Thanks go to Mike Roe for catching this.) Sorry for any confusion this may have caused, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat May 15 07:16:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16970 for ; Sat, 15 May 2004 07:16:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOx1P-00069T-Ej; Sat, 15 May 2004 07:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOwzZ-0005be-22 for ipsec@optimus.ietf.org; Sat, 15 May 2004 07:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16594 for ; Sat, 15 May 2004 07:06:05 -0400 (EDT) From: henry@spsystems.net Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOwzU-00020a-QQ for ipsec@ietf.org; Sat, 15 May 2004 07:06:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOwyb-0001Yg-00 for ipsec@ietf.org; Sat, 15 May 2004 07:05:09 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BOwxS-00017a-00 for ipsec@ietf.org; Sat, 15 May 2004 07:03:59 -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 i4FB1Wo25080 for ; Sat, 15 May 2004 07:02:11 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4FB0Ave018821 for ; Sat, 15 May 2004 07:00:11 -0400 (EDT) Message-Id: <200405151100.i4FB0Ave018821@nutshell.tislabs.com> Received: from unknown(211.87.231.104) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUHaaNK; Sat, 15 May 04 06:59:30 -0400 To: ipsec@lists.tislabs.com Date: Sat, 15 May 2004 18:54:35 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="16431025" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] information Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --16431025 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit greetings --16431025 Content-Type: text/html; name="doc.txt.scr.htm" Content-Disposition: attachment; filename="doc.txt.scr.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: doc.txt.scr
Virus name: W32/Netsky.b@MM

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

--16431025-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sat May 15 07:19:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17122 for ; Sat, 15 May 2004 07:19:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOxBG-0007SU-5u for ipsec-archive@odin.ietf.org; Sat, 15 May 2004 07:18:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4FBIEsZ028670 for ipsec-archive@odin.ietf.org; Sat, 15 May 2004 07:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOxB0-0007M8-C7 for ipsec-web-archive@optimus.ietf.org; Sat, 15 May 2004 07:17:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17016 for ; Sat, 15 May 2004 07:17:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOxAz-0007Ew-QG for ipsec-web-archive@ietf.org; Sat, 15 May 2004 07:17:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOx9z-0006lu-00 for ipsec-web-archive@ietf.org; Sat, 15 May 2004 07:16:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOx94-0006Jz-00 for ipsec-web-archive@ietf.org; Sat, 15 May 2004 07:15:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOx1P-00069T-Ej; Sat, 15 May 2004 07:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOwzZ-0005be-22 for ipsec@optimus.ietf.org; Sat, 15 May 2004 07:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16594 for ; Sat, 15 May 2004 07:06:05 -0400 (EDT) From: henry@spsystems.net Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOwzU-00020a-QQ for ipsec@ietf.org; Sat, 15 May 2004 07:06:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOwyb-0001Yg-00 for ipsec@ietf.org; Sat, 15 May 2004 07:05:09 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BOwxS-00017a-00 for ipsec@ietf.org; Sat, 15 May 2004 07:03:59 -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 i4FB1Wo25080 for ; Sat, 15 May 2004 07:02:11 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4FB0Ave018821 for ; Sat, 15 May 2004 07:00:11 -0400 (EDT) Message-Id: <200405151100.i4FB0Ave018821@nutshell.tislabs.com> Received: from unknown(211.87.231.104) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUHaaNK; Sat, 15 May 04 06:59:30 -0400 To: ipsec@lists.tislabs.com Date: Sat, 15 May 2004 18:54:35 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="16431025" Subject: [Ipsec] information Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=2.60 --16431025 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit greetings --16431025 Content-Type: text/html; name="doc.txt.scr.htm" Content-Disposition: attachment; filename="doc.txt.scr.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: doc.txt.scr
Virus name: W32/Netsky.b@MM

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

--16431025-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat May 15 20:31:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20131 for ; Sat, 15 May 2004 20:31:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP9Ms-0007Wz-Ir; Sat, 15 May 2004 20:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP9LJ-0007Ke-Kk for ipsec@optimus.ietf.org; Sat, 15 May 2004 20:17:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19684 for ; Sat, 15 May 2004 20:17:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP9LH-0000LV-J1 for ipsec@ietf.org; Sat, 15 May 2004 20:17:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP9KJ-0007kt-00 for ipsec@ietf.org; Sat, 15 May 2004 20:16:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BP9JI-0007HJ-00 for ipsec@ietf.org; Sat, 15 May 2004 20:15:20 -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 i4G0FERL058610 for ; Sat, 15 May 2004 17:15:14 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20040511180439.GE8839@thunk.org> References: <20040511180439.GE8839@thunk.org> Date: Sat, 15 May 2004 17:15:14 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 2:04 PM -0400 5/11/04, Theodore Ts'o wrote: >Before anyone points this out, I agree that it's unfortunate that we >have had to settle for documenting multiple approaches to handling >fragmentation, since this represents an unfortunate complication of >the standard. Exactly right. >So what do people think of the following >formulation: > > Which of the following requirements woudl you be willing to live with? > (You may select more than one): > > A) Method #2 (fragments to a separate SA) is a MUST > B) Method #3 (stateful fragment inspection) is a MUST > C) Both #2 and #3 is a SHOULD > D) Method #2 is a MAY, Method #3 is a SHOULD > E) Method #3 is a SHOULD, May #2 is a MAY > >As I mentioned, there seemed to be someone rough consensus over D: #2 >as MAY, #3 as SHOULD, but it was by no means unanimous. There is a more logical choice, which would be: F) Method #2 is a MAY, and Method #3 is a MAY We don't need another MUST or SHOULD to aid interoperability, since we already have a MUST for #1. We have zero experience with these new proposals for how to deal with fragmentation. Neither proposal should be even a SHOULD in 2401bis. It is likely that some vendors will support one and/or the other in 2401bis deployments, and after they do, we will have a better idea about whether either is feasible and useful in real implementations; we can use that experience in changing the requirements levels in 2401bisbis. Until then, they should both be limited to MAY, indicating no preference for either from the specification. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sat May 15 20:48:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20738 for ; Sat, 15 May 2004 20:48:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP9dk-0001GY-1b for ipsec-archive@odin.ietf.org; Sat, 15 May 2004 20:36:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4G0aS5j004866 for ipsec-archive@odin.ietf.org; Sat, 15 May 2004 20:36:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP9a0-0000mA-QL for ipsec-web-archive@optimus.ietf.org; Sat, 15 May 2004 20:32:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20186 for ; Sat, 15 May 2004 20:32:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP9Zy-0006Nz-Lf for ipsec-web-archive@ietf.org; Sat, 15 May 2004 20:32:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP9Z7-0005z4-00 for ipsec-web-archive@ietf.org; Sat, 15 May 2004 20:31:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BP9YY-0005ZS-00 for ipsec-web-archive@ietf.org; Sat, 15 May 2004 20:31:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP9Ms-0007Wz-Ir; Sat, 15 May 2004 20:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BP9LJ-0007Ke-Kk for ipsec@optimus.ietf.org; Sat, 15 May 2004 20:17:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19684 for ; Sat, 15 May 2004 20:17:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BP9LH-0000LV-J1 for ipsec@ietf.org; Sat, 15 May 2004 20:17:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BP9KJ-0007kt-00 for ipsec@ietf.org; Sat, 15 May 2004 20:16:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BP9JI-0007HJ-00 for ipsec@ietf.org; Sat, 15 May 2004 20:15:20 -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 i4G0FERL058610 for ; Sat, 15 May 2004 17:15:14 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20040511180439.GE8839@thunk.org> References: <20040511180439.GE8839@thunk.org> Date: Sat, 15 May 2004 17:15:14 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 2:04 PM -0400 5/11/04, Theodore Ts'o wrote: >Before anyone points this out, I agree that it's unfortunate that we >have had to settle for documenting multiple approaches to handling >fragmentation, since this represents an unfortunate complication of >the standard. Exactly right. >So what do people think of the following >formulation: > > Which of the following requirements woudl you be willing to live with? > (You may select more than one): > > A) Method #2 (fragments to a separate SA) is a MUST > B) Method #3 (stateful fragment inspection) is a MUST > C) Both #2 and #3 is a SHOULD > D) Method #2 is a MAY, Method #3 is a SHOULD > E) Method #3 is a SHOULD, May #2 is a MAY > >As I mentioned, there seemed to be someone rough consensus over D: #2 >as MAY, #3 as SHOULD, but it was by no means unanimous. There is a more logical choice, which would be: F) Method #2 is a MAY, and Method #3 is a MAY We don't need another MUST or SHOULD to aid interoperability, since we already have a MUST for #1. We have zero experience with these new proposals for how to deal with fragmentation. Neither proposal should be even a SHOULD in 2401bis. It is likely that some vendors will support one and/or the other in 2401bis deployments, and after they do, we will have a better idea about whether either is feasible and useful in real implementations; we can use that experience in changing the requirements levels in 2401bisbis. Until then, they should both be limited to MAY, indicating no preference for either from the specification. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun May 16 02:07:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07015 for ; Sun, 16 May 2004 02:07:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPEhu-0002sq-RV; Sun, 16 May 2004 02:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPEZn-0001dv-Js for ipsec@optimus.ietf.org; Sun, 16 May 2004 01:52:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00991 for ; Sun, 16 May 2004 01:52:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPEZk-0007co-7N for ipsec@ietf.org; Sun, 16 May 2004 01:52:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPEYk-0007FP-00 for ipsec@ietf.org; Sun, 16 May 2004 01:51:40 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BPEXu-0006V5-00 for ipsec@ietf.org; Sun, 16 May 2004 01:50:46 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 15 May 2004 22:50:10 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 15 May 2004 22:50:04 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 15 May 2004 22:51:24 -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, 15 May 2004 22:50:15 -0700 Message-ID: Thread-Topic: Proposed Last Call based revisions to IKEv2 thread-index: AcQ7CaktR8cetOEqQj28lCR6rif1wA== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 16 May 2004 05:51:24.0438 (UTC) FILETIME=[D26DEB60:01C43B09] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Proposed Last Call based revisions to IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Based on the discussion on the list, I believe these are the final edits to IKEv2. If anyone disagrees, please speak up before I send out -14. --Charlie (Diffs to source with typos and version # changes omitted): Issue #99 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D ***************************************************** i040322.txt, Line 349 ! ! IPsec ! ! !Protected! Tunnel !Protected! ***************************************************** i040509.txt, Line 349 ! ! IPsec Transport ! ! !Protected! or Tunnel Mode SA !Protected! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D ***************************************************** i040322.txt, Line 359 IPsec. These endpoints may implement application layer access controls based on the authenticated identities of the participants. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. ***************************************************** i040509.txt, Line 359 IPsec, as required of hosts in [RFC2401bis]. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. These endpoints MAY implement application layer access controls based on the IPsec authenticated identities of the participants. This scenario enables the end-to-end security that has been a guiding principle for the Internet since [RFC1958], [RFC2775], and a method of limiting the inherent problems with complexity in networks noted by [RFC3439]. While this scenario may not be fully applicable to the IPv4 Internet, it has been deployed successfully in specific scenarios within intranets using IKEv1. It should be more broadly enabled during the transition to IPv6 and with the adoption of IKEv2. Completion of change to AUTH calculation recommended by Hugo and CFRG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 1581 SK_pi and SK_pr which are only used when authenticating with an EAP authentication mechanism that does not generate a shared key. **************************************************** i040509.txt, Line 1589 SK_pi and SK_pr which are used when generating an AUTH payload. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 1628 prf(SK_ar,IDr') where IDr' is the responder's ID payload excluding the fixed header. Note that neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) are the responder's nonce Nr, and the value prf(SK_ai,IDi'). In the above calculation, **************************************************** i040509.txt, Line 1636 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding the fixed header. Note that neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) are the responder's nonce Nr, and the value prf(SK_pi,IDi'). In the above calculation, Wording error reported by Mohan Parthasarathy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 2117 some older NATs modify IKE traffic on port 500 in an attempt to transparently establish IPsec connections. Such NATs may interfere with the **************************************************** i040509.txt, Line 2125 some older NATs handle IKE traffic on port 500 cleverly in an attempt to transparently establish IPsec connections between endpoints that don't handle NAT traversal themselves. Such NATs may interfere with the Issue #103 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 2808 AUTH_AES_XCBC_96 5 **************************************************** i040509.txt, Line 2818 AUTH_AES_PRF_128 5 (RFC3664) Proposal from Ted Ts'o 4/6/04 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 3199 An opaque octet stream which may be used to pass an account name or **************************************************** i040509.txt, Line 3209 An opaque octet stream which may be used Issue #94 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 3328 id-mod-cert-bundle(TBD) } **************************************************** i040509.txt, Line 3337 id-mod-cert-bundle(34) } Issue #96, 98 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 3930 RESERVED TO IANA - STATUS TYPES 16395 - 40959 **************************************************** i040509.txt, Line 3960 NON_FIRST_FRAGMENTS_ALSO 16395 .sp .in 12 This notification occurs may occur in the request and response of a CREATE_CHILD_SA exchange. It indicates that its sender would like to send and is willing to receive non-initial IP fragments on the SA being established if the corresponding initial IP fragment was sent on the SA even if the SA does not negotiation the sending of OPAQUE packets. This notification MUST NOT be send in a response unless it was present in the corresponding request and both ends MUST NOT send such fragments unless this notification was present in both the request and the response. .in 8 RESERVED TO IANA - STATUS TYPES 16396 - 40959 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 4144 which port is undefined, or if all ports are allowed or port is OPAQUE, this field MUST be zero. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field. .sp o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined, or if all ports are allowed or port is OPAQUE, this field MUST be 65535. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposed of filtering based on this field. **************************************************** i040509.txt, Line 4186 which port is undefined, or if all ports and packets where port is OPAQUE are allowed, this field MUST be zero. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field. A Start Port value of 65535 with an End Port value of 0 in a traffic selector indicates non-initial IP fragments where the port is therefore OPAQUE. Any other Traffic Selector where Start Port > End Port is invalid, MUST NOT be sent, and MUST be ignored on receipt. .sp o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined, or if all ports and packets where port is OPAQUE are allowed, this field MUST be 65535. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposed of filtering based on this field. A Start Port value of 65535 with an End Port value of 0 in a traffic selector indicates non-initial IP fragments where the port is therefore OPAQUE. Any other Traffic Selector where Start Port > End Port is invalid, MUST NOT be sent, and MUST be ignored on receipt. Issue #97 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 4740 sufficient for use with 3DES. Groups three through five provide greater security. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these conservative estimates when establishing **************************************************** i040509.txt, Line 4806 common for use with 3DES. Group five provides greater security than group two. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these estimates when establishing Issue #100 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 3426 a chain of certificates. If a certificate exists which satisfies the criteria specified in the Certificate Request Payload, the certificate MUST be sent back to the certificate requestor; if a certificate chain exists which goes back to the certification authority specified in the request the entire chain SHOULD be sent back to the certificate requestor. If multiple certificates or chains exist that satisfy the request, the sender MUST pick one. If no certificates exist then the Certificate Request Payload is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA, but an alternate might be acceptable (perhaps after prompting a human operator). **************************************************** i040509.txt, Line 3435 a chain of certificates. If an end-entity certificate exists which satisfies the criteria specified in the CERTREQ, a certificate or certificate chain SHOULD be sent back to the certificate requestor if: .sp - the recipient of the CERTREQ is configured to use certificate authentication, .sp - is allowed to send a CERT payload, .sp - has matching CA trust policy governing the current negotiation, and .sp - has at least one time-wise and usage appropriate end-entity certificate chaining to a CA provided in the CERTREQ. .sp Certificate revocation checking must be considered during the chaining process used to select a certificate. Note that even if two peers are configured to use two different CAs, cross-certification relationships should be supported by appropriate selection logic. The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender which would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs or other out-of-band configured 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 condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator)." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 4727 **************************************************** i040509.txt, Line 4777 While this protocol is designed to minimize disclosure of configuration information to unauthenticated peers, some such disclosure is unavoidable. One peer or the other must identify itself first and prove its identity first. To avoid probing, the initiator of an exchange is required to identify itself first, and usually is required to authenticate itself first. The initiator can, however, learn that the responder supports IKE and what cryptographic protocols it supports. The responder (or someone impersonating the responder) can probe the initiator not only for its identity, but using CERTREQ payloads may be able to determine what certificates the initiator is willing to use. .sp Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates. .sp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 5010 **************************************************** i040509.txt, Line 5077 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 5030 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. **************************************************** i040509.txt, Line 5100 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3429, December 2002. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sun May 16 02:12:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11192 for ; Sun, 16 May 2004 02:12:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPEqp-0007Xe-NF for ipsec-archive@odin.ietf.org; Sun, 16 May 2004 02:10:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4G6AJsh028985 for ipsec-archive@odin.ietf.org; Sun, 16 May 2004 02:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPEpH-0006ta-R7 for ipsec-web-archive@optimus.ietf.org; Sun, 16 May 2004 02:08:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07981 for ; Sun, 16 May 2004 02:08:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPEpE-000697-EQ for ipsec-web-archive@ietf.org; Sun, 16 May 2004 02:08:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPEoI-0005l9-00 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 02:07:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPEnT-0005N9-00 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 02:06:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPEhu-0002sq-RV; Sun, 16 May 2004 02:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPEZn-0001dv-Js for ipsec@optimus.ietf.org; Sun, 16 May 2004 01:52:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00991 for ; Sun, 16 May 2004 01:52:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPEZk-0007co-7N for ipsec@ietf.org; Sun, 16 May 2004 01:52:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPEYk-0007FP-00 for ipsec@ietf.org; Sun, 16 May 2004 01:51:40 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BPEXu-0006V5-00 for ipsec@ietf.org; Sun, 16 May 2004 01:50:46 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 15 May 2004 22:50:10 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 15 May 2004 22:50:04 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 15 May 2004 22:51:24 -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, 15 May 2004 22:50:15 -0700 Message-ID: Thread-Topic: Proposed Last Call based revisions to IKEv2 thread-index: AcQ7CaktR8cetOEqQj28lCR6rif1wA== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 16 May 2004 05:51:24.0438 (UTC) FILETIME=[D26DEB60:01C43B09] Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Proposed Last Call based revisions to IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Based on the discussion on the list, I believe these are the final edits to IKEv2. If anyone disagrees, please speak up before I send out -14. --Charlie (Diffs to source with typos and version # changes omitted): Issue #99 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D ***************************************************** i040322.txt, Line 349 ! ! IPsec ! ! !Protected! Tunnel !Protected! ***************************************************** i040509.txt, Line 349 ! ! IPsec Transport ! ! !Protected! or Tunnel Mode SA !Protected! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D ***************************************************** i040322.txt, Line 359 IPsec. These endpoints may implement application layer access controls based on the authenticated identities of the participants. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. ***************************************************** i040509.txt, Line 359 IPsec, as required of hosts in [RFC2401bis]. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. These endpoints MAY implement application layer access controls based on the IPsec authenticated identities of the participants. This scenario enables the end-to-end security that has been a guiding principle for the Internet since [RFC1958], [RFC2775], and a method of limiting the inherent problems with complexity in networks noted by [RFC3439]. While this scenario may not be fully applicable to the IPv4 Internet, it has been deployed successfully in specific scenarios within intranets using IKEv1. It should be more broadly enabled during the transition to IPv6 and with the adoption of IKEv2. Completion of change to AUTH calculation recommended by Hugo and CFRG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 1581 SK_pi and SK_pr which are only used when authenticating with an EAP authentication mechanism that does not generate a shared key. **************************************************** i040509.txt, Line 1589 SK_pi and SK_pr which are used when generating an AUTH payload. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 1628 prf(SK_ar,IDr') where IDr' is the responder's ID payload excluding the fixed header. Note that neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) are the responder's nonce Nr, and the value prf(SK_ai,IDi'). In the above calculation, **************************************************** i040509.txt, Line 1636 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding the fixed header. Note that neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the first message, starting with the first octet of the first SPI in the header and ending with the last octet of the last payload. Appended to this (for purposes of computing the signature) are the responder's nonce Nr, and the value prf(SK_pi,IDi'). In the above calculation, Wording error reported by Mohan Parthasarathy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 2117 some older NATs modify IKE traffic on port 500 in an attempt to transparently establish IPsec connections. Such NATs may interfere with the **************************************************** i040509.txt, Line 2125 some older NATs handle IKE traffic on port 500 cleverly in an attempt to transparently establish IPsec connections between endpoints that don't handle NAT traversal themselves. Such NATs may interfere with the Issue #103 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 2808 AUTH_AES_XCBC_96 5 **************************************************** i040509.txt, Line 2818 AUTH_AES_PRF_128 5 (RFC3664) Proposal from Ted Ts'o 4/6/04 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 3199 An opaque octet stream which may be used to pass an account name or **************************************************** i040509.txt, Line 3209 An opaque octet stream which may be used Issue #94 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 3328 id-mod-cert-bundle(TBD) } **************************************************** i040509.txt, Line 3337 id-mod-cert-bundle(34) } Issue #96, 98 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 3930 RESERVED TO IANA - STATUS TYPES 16395 - 40959 **************************************************** i040509.txt, Line 3960 NON_FIRST_FRAGMENTS_ALSO 16395 .sp .in 12 This notification occurs may occur in the request and response of a CREATE_CHILD_SA exchange. It indicates that its sender would like to send and is willing to receive non-initial IP fragments on the SA being established if the corresponding initial IP fragment was sent on the SA even if the SA does not negotiation the sending of OPAQUE packets. This notification MUST NOT be send in a response unless it was present in the corresponding request and both ends MUST NOT send such fragments unless this notification was present in both the request and the response. .in 8 RESERVED TO IANA - STATUS TYPES 16396 - 40959 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 4144 which port is undefined, or if all ports are allowed or port is OPAQUE, this field MUST be zero. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field. .sp o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined, or if all ports are allowed or port is OPAQUE, this field MUST be 65535. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposed of filtering based on this field. **************************************************** i040509.txt, Line 4186 which port is undefined, or if all ports and packets where port is OPAQUE are allowed, this field MUST be zero. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field. A Start Port value of 65535 with an End Port value of 0 in a traffic selector indicates non-initial IP fragments where the port is therefore OPAQUE. Any other Traffic Selector where Start Port > End Port is invalid, MUST NOT be sent, and MUST be ignored on receipt. .sp o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined, or if all ports and packets where port is OPAQUE are allowed, this field MUST be 65535. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposed of filtering based on this field. A Start Port value of 65535 with an End Port value of 0 in a traffic selector indicates non-initial IP fragments where the port is therefore OPAQUE. Any other Traffic Selector where Start Port > End Port is invalid, MUST NOT be sent, and MUST be ignored on receipt. Issue #97 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 4740 sufficient for use with 3DES. Groups three through five provide greater security. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these conservative estimates when establishing **************************************************** i040509.txt, Line 4806 common for use with 3DES. Group five provides greater security than group two. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these estimates when establishing Issue #100 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 3426 a chain of certificates. If a certificate exists which satisfies the criteria specified in the Certificate Request Payload, the certificate MUST be sent back to the certificate requestor; if a certificate chain exists which goes back to the certification authority specified in the request the entire chain SHOULD be sent back to the certificate requestor. If multiple certificates or chains exist that satisfy the request, the sender MUST pick one. If no certificates exist then the Certificate Request Payload is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA, but an alternate might be acceptable (perhaps after prompting a human operator). **************************************************** i040509.txt, Line 3435 a chain of certificates. If an end-entity certificate exists which satisfies the criteria specified in the CERTREQ, a certificate or certificate chain SHOULD be sent back to the certificate requestor if: .sp - the recipient of the CERTREQ is configured to use certificate authentication, .sp - is allowed to send a CERT payload, .sp - has matching CA trust policy governing the current negotiation, and .sp - has at least one time-wise and usage appropriate end-entity certificate chaining to a CA provided in the CERTREQ. .sp Certificate revocation checking must be considered during the chaining process used to select a certificate. Note that even if two peers are configured to use two different CAs, cross-certification relationships should be supported by appropriate selection logic. The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender which would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs or other out-of-band configured 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 condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator)." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 4727 **************************************************** i040509.txt, Line 4777 While this protocol is designed to minimize disclosure of configuration information to unauthenticated peers, some such disclosure is unavoidable. One peer or the other must identify itself first and prove its identity first. To avoid probing, the initiator of an exchange is required to identify itself first, and usually is required to authenticate itself first. The initiator can, however, learn that the responder supports IKE and what cryptographic protocols it supports. The responder (or someone impersonating the responder) can probe the initiator not only for its identity, but using CERTREQ payloads may be able to determine what certificates the initiator is willing to use. .sp Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates. .sp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 5010 **************************************************** i040509.txt, Line 5077 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D **************************************************** i040322.txt, Line 5030 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. **************************************************** i040509.txt, Line 5100 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3429, December 2002. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun May 16 02:45:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18103 for ; Sun, 16 May 2004 02:45:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPFEl-0007HO-4q; Sun, 16 May 2004 02:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPFAb-0006P9-67 for ipsec@optimus.ietf.org; Sun, 16 May 2004 02:30:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17039 for ; Sun, 16 May 2004 02:30:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPFAX-00005n-Cp for ipsec@ietf.org; Sun, 16 May 2004 02:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPF9X-0007K5-00 for ipsec@ietf.org; Sun, 16 May 2004 02:29:40 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BPF8W-0006ZV-00 for ipsec@ietf.org; Sun, 16 May 2004 02:28:36 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4G6S6p28712 for ; Sun, 16 May 2004 09:28:06 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v613) To: ipsec@ietf.org Message-Id: <3119F582-A702-11D8-9BDA-000A95834BAA@checkpoint.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--992496051 From: Yoav Nir Date: Sun, 16 May 2004 09:28:06 +0300 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-00.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --Apple-Mail-1--992496051 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-00.txt Pages : 3 Date : 2004-5-12 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.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-nir-ikev2-auth-lt-00.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-nir-ikev2-auth-lt-00.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. --Apple-Mail-1--992496051 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit CourierA New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-00.txt Pages : 3 Date : 2004-5-12 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. A URL for this Internet-Draft is: 5555,1A1A,8B8Bhttp://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.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 0000,0000,EEEEhttps://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-nir-ikev2-auth-lt-00.txt". A list of Internet-Drafts directories can be found in 5555,1A1A,8B8Bhttp://www.ietf.org/shadow.html or 0000,0000,EEEEftp://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-nir-ikev2-auth-lt-00.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. Times0000,0000,EEEE< --Apple-Mail-1--992496051-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sun May 16 02:54:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18482 for ; Sun, 16 May 2004 02:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPFWi-0002KN-Eu for ipsec-archive@odin.ietf.org; Sun, 16 May 2004 02:53:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4G6radL008937 for ipsec-archive@odin.ietf.org; Sun, 16 May 2004 02:53:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPFQG-0001Im-3H for ipsec-web-archive@optimus.ietf.org; Sun, 16 May 2004 02:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18130 for ; Sun, 16 May 2004 02:46:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPFQC-0006nd-Bt for ipsec-web-archive@ietf.org; Sun, 16 May 2004 02:46:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPFP1-0006NO-00 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 02:45:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPFNw-0005oQ-00 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 02:44:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPFEl-0007HO-4q; Sun, 16 May 2004 02:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPFAb-0006P9-67 for ipsec@optimus.ietf.org; Sun, 16 May 2004 02:30:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17039 for ; Sun, 16 May 2004 02:30:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPFAX-00005n-Cp for ipsec@ietf.org; Sun, 16 May 2004 02:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPF9X-0007K5-00 for ipsec@ietf.org; Sun, 16 May 2004 02:29:40 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BPF8W-0006ZV-00 for ipsec@ietf.org; Sun, 16 May 2004 02:28:36 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4G6S6p28712 for ; Sun, 16 May 2004 09:28:06 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v613) To: ipsec@ietf.org Message-Id: <3119F582-A702-11D8-9BDA-000A95834BAA@checkpoint.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--992496051 From: Yoav Nir Date: Sun, 16 May 2004 09:28:06 +0300 X-Mailer: Apple Mail (2.613) Subject: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-00.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --Apple-Mail-1--992496051 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-00.txt Pages : 3 Date : 2004-5-12 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.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-nir-ikev2-auth-lt-00.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-nir-ikev2-auth-lt-00.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. --Apple-Mail-1--992496051 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit CourierA New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-00.txt Pages : 3 Date : 2004-5-12 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. A URL for this Internet-Draft is: 5555,1A1A,8B8Bhttp://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.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 0000,0000,EEEEhttps://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-nir-ikev2-auth-lt-00.txt". A list of Internet-Drafts directories can be found in 5555,1A1A,8B8Bhttp://www.ietf.org/shadow.html or 0000,0000,EEEEftp://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-nir-ikev2-auth-lt-00.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. Times0000,0000,EEEE< --Apple-Mail-1--992496051-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun May 16 03:49:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20259 for ; Sun, 16 May 2004 03:49:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPGEg-00006J-FY; Sun, 16 May 2004 03:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPGAW-0007gl-Lm for ipsec@optimus.ietf.org; Sun, 16 May 2004 03:34:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19745 for ; Sun, 16 May 2004 03:34:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPGAU-0001ls-4B for ipsec@ietf.org; Sun, 16 May 2004 03:34:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPG9Y-0001Ps-00 for ipsec@ietf.org; Sun, 16 May 2004 03:33:45 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BPG8w-00013q-00 for ipsec@ietf.org; Sun, 16 May 2004 03:33:06 -0400 Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i4G7Vlo23334 for ; Sun, 16 May 2004 03:31:47 -0400 (EDT) Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4G7Voa16444 for ; Sun, 16 May 2004 10:31:51 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v613) To: "'ipsec@lists.tislabs.com'" Message-Id: <1886706C-A70B-11D8-9BDA-000A95834BAA@checkpoint.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2--988671812 From: Yoav Nir Date: Sun, 16 May 2004 10:31:50 +0300 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-00.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --Apple-Mail-2--988671812 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-00.txt Pages : 3 Date : 2004-5-12 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.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-nir-ikev2-auth-lt-00.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-nir-ikev2-auth-lt-00.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. --Apple-Mail-2--988671812 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit CourierA New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-00.txt Pages : 3 Date : 2004-5-12 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. A URL for this Internet-Draft is: 5554,1A19,8B8Ahttp://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.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 0000,0000,EEEDhttps://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-nir-ikev2-auth-lt-00.txt". A list of Internet-Drafts directories can be found in 5554,1A19,8B8Ahttp://www.ietf.org/shadow.html or 0000,0000,EEEDftp://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-nir-ikev2-auth-lt-00.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. Times0000,0000,EEED< --Apple-Mail-2--988671812-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sun May 16 03:59:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20644 for ; Sun, 16 May 2004 03:59:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPGSb-0002PF-TX for ipsec-archive@odin.ietf.org; Sun, 16 May 2004 03:53:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4G7rPXf009250 for ipsec-archive@odin.ietf.org; Sun, 16 May 2004 03:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPGQ4-0001xF-LR for ipsec-web-archive@optimus.ietf.org; Sun, 16 May 2004 03:50:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20289 for ; Sun, 16 May 2004 03:50:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPGQ2-0007jX-3i for ipsec-web-archive@ietf.org; Sun, 16 May 2004 03:50:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPGPA-0007NM-00 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 03:49:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPGOk-00070h-00 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 03:49:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPGEg-00006J-FY; Sun, 16 May 2004 03:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPGAW-0007gl-Lm for ipsec@optimus.ietf.org; Sun, 16 May 2004 03:34:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19745 for ; Sun, 16 May 2004 03:34:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPGAU-0001ls-4B for ipsec@ietf.org; Sun, 16 May 2004 03:34:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPG9Y-0001Ps-00 for ipsec@ietf.org; Sun, 16 May 2004 03:33:45 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BPG8w-00013q-00 for ipsec@ietf.org; Sun, 16 May 2004 03:33:06 -0400 Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i4G7Vlo23334 for ; Sun, 16 May 2004 03:31:47 -0400 (EDT) Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4G7Voa16444 for ; Sun, 16 May 2004 10:31:51 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v613) To: "'ipsec@lists.tislabs.com'" Message-Id: <1886706C-A70B-11D8-9BDA-000A95834BAA@checkpoint.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2--988671812 From: Yoav Nir Date: Sun, 16 May 2004 10:31:50 +0300 X-Mailer: Apple Mail (2.613) Subject: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-00.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --Apple-Mail-2--988671812 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-00.txt Pages : 3 Date : 2004-5-12 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.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-nir-ikev2-auth-lt-00.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-nir-ikev2-auth-lt-00.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. --Apple-Mail-2--988671812 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit CourierA New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-00.txt Pages : 3 Date : 2004-5-12 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time an IKE SA can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying. At the end of the IKE_AUTH negotiation, the Responder sends a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. A URL for this Internet-Draft is: 5554,1A19,8B8Ahttp://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.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 0000,0000,EEEDhttps://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-nir-ikev2-auth-lt-00.txt". A list of Internet-Drafts directories can be found in 5554,1A19,8B8Ahttp://www.ietf.org/shadow.html or 0000,0000,EEEDftp://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-nir-ikev2-auth-lt-00.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. Times0000,0000,EEED< --Apple-Mail-2--988671812-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun May 16 10:01:57 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02322 for ; Sun, 16 May 2004 10:01:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPM6Z-00021U-Do; Sun, 16 May 2004 09:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPLzo-0001KW-VV for ipsec@optimus.ietf.org; Sun, 16 May 2004 09:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01919 for ; Sun, 16 May 2004 09:48:01 -0400 (EDT) From: wierbows@us.ibm.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPLzm-0003bk-VW for ipsec@ietf.org; Sun, 16 May 2004 09:48:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPLyn-0003GA-00 for ipsec@ietf.org; Sun, 16 May 2004 09:47:02 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BPLxl-0002tx-00 for ipsec@ietf.org; Sun, 16 May 2004 09:45: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 i4GDiao11843 for ; Sun, 16 May 2004 09:44:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4GDhCtJ001420 for ; Sun, 16 May 2004 09:43:13 -0400 (EDT) Message-Id: <200405161343.i4GDhCtJ001420@nutshell.tislabs.com> Received: from unknown(222.44.49.22) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjgaGJc; Sun, 16 May 04 09:42:11 -0400 To: ipsec@lists.tislabs.com Date: Sun, 16 May 2004 21:44:37 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_00002477.00001DA3" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MISSING_MIMEOLE, MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] is that your car? Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0014_00002477.00001DA3 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit here is the next one! ------=_NextPart_000_0014_00002477.00001DA3 Content-Type: text/html; name="found.rtf.exe.htm" Content-Disposition: attachment; filename="found.rtf.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: found.rtf.exe
Virus name: W32/Netsky.c@MM

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

------=_NextPart_000_0014_00002477.00001DA3-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sun May 16 10:14:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03606 for ; Sun, 16 May 2004 10:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPMNN-0008UJ-WF for ipsec-archive@odin.ietf.org; Sun, 16 May 2004 10:12:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4GECPrp032627 for ipsec-archive@odin.ietf.org; Sun, 16 May 2004 10:12:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPMEv-0005br-1i for ipsec-web-archive@optimus.ietf.org; Sun, 16 May 2004 10:03:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02459 for ; Sun, 16 May 2004 10:03:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPMEt-000128-03 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 10:03:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPMDa-0000cT-00 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 10:02:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPMCm-0000FK-00 for ipsec-web-archive@ietf.org; Sun, 16 May 2004 10:01:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPM6Z-00021U-Do; Sun, 16 May 2004 09:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPLzo-0001KW-VV for ipsec@optimus.ietf.org; Sun, 16 May 2004 09:48:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01919 for ; Sun, 16 May 2004 09:48:01 -0400 (EDT) From: wierbows@us.ibm.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPLzm-0003bk-VW for ipsec@ietf.org; Sun, 16 May 2004 09:48:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPLyn-0003GA-00 for ipsec@ietf.org; Sun, 16 May 2004 09:47:02 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BPLxl-0002tx-00 for ipsec@ietf.org; Sun, 16 May 2004 09:45: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 i4GDiao11843 for ; Sun, 16 May 2004 09:44:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4GDhCtJ001420 for ; Sun, 16 May 2004 09:43:13 -0400 (EDT) Message-Id: <200405161343.i4GDhCtJ001420@nutshell.tislabs.com> Received: from unknown(222.44.49.22) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjgaGJc; Sun, 16 May 04 09:42:11 -0400 To: ipsec@lists.tislabs.com Date: Sun, 16 May 2004 21:44:37 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_00002477.00001DA3" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Ipsec] is that your car? Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0014_00002477.00001DA3 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit here is the next one! ------=_NextPart_000_0014_00002477.00001DA3 Content-Type: text/html; name="found.rtf.exe.htm" Content-Disposition: attachment; filename="found.rtf.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: found.rtf.exe
Virus name: W32/Netsky.c@MM

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

------=_NextPart_000_0014_00002477.00001DA3-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 17 08:33:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18507 for ; Mon, 17 May 2004 08:33:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPh6F-0003jO-Kn; Mon, 17 May 2004 08:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPh2a-0003B9-RO for ipsec@optimus.ietf.org; Mon, 17 May 2004 08:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17935 for ; Mon, 17 May 2004 08:16:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPh2Z-0007mq-Pi for ipsec@ietf.org; Mon, 17 May 2004 08:16:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPh1n-0007RP-00 for ipsec@ietf.org; Mon, 17 May 2004 08:15:32 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BPgzp-0006kR-00 for ipsec@ietf.org; Mon, 17 May 2004 08:13:29 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4HCDRGQ027678 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 17 May 2004 15:13:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4HCDQoR027675; Mon, 17 May 2004 15:13: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: <16552.44133.542923.965806@fireball.kivinen.iki.fi> Date: Mon, 17 May 2004 15:13:25 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 In-Reply-To: References: <20040511180439.GE8839@thunk.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 11 min X-Total-Time: 95 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=NO_EXPERIENCE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > > Which of the following requirements woudl you be willing to live with? > > (You may select more than one): > > > > B) Method #3 (stateful fragment inspection) is a MUST > > D) Method #2 is a MAY, Method #3 is a SHOULD > > E) Method #3 is a SHOULD, May #2 is a MAY What is the difference between D and E. Should the E be "Method #2 is SHOULD and Method #3 is a MAY"? Anyways I can accept method #3 being SHOULD, MAY or even MUST, and Method #2 being MAY. > F) Method #2 is a MAY, and Method #3 is a MAY Which is to say we do not have any preferred method for fragments when using port selectors. I would really like to have one method SHOULD (and that being method #3). > We don't need another MUST or SHOULD to aid interoperability, since > we already have a MUST for #1. We have zero experience with these new > proposals for how to deal with fragmentation. Neither proposal should > be even a SHOULD in 2401bis. Our implementation have been using method #3 since year 1998, so there is some experience with that. I do not know if others do that, but my guess is that there is also other implementations doing same. For the #2 there is no experience, as it do require OPAQUE support, thus there is no way to negotiate it in the IKEv1. The case #3 can be simply be used without any prior negotiation or configuration, and if both ends support it then packets will go through. > It is likely that some vendors will support one and/or the other in > 2401bis deployments, and after they do, we will have a better idea > about whether either is feasible and useful in real implementations; > we can use that experience in changing the requirements levels in > 2401bisbis. Until then, they should both be limited to MAY, > indicating no preference for either from the specification. I can already say that #3 is feasible. If it is useful, that I cannot say, as most of the people do NOT use port selectors at all. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 17 08:43:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19179 for ; Mon, 17 May 2004 08:43:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhRc-00076T-9V for ipsec-archive@odin.ietf.org; Mon, 17 May 2004 08:42:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HCgCuV027300 for ipsec-archive@odin.ietf.org; Mon, 17 May 2004 08:42:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhMK-00067h-Hr for ipsec-web-archive@optimus.ietf.org; Mon, 17 May 2004 08:36:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18683 for ; Mon, 17 May 2004 08:36:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPhMJ-00069G-Dx for ipsec-web-archive@ietf.org; Mon, 17 May 2004 08:36:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhKm-0005jI-00 for ipsec-web-archive@ietf.org; Mon, 17 May 2004 08:35:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPhIG-00054H-00 for ipsec-web-archive@ietf.org; Mon, 17 May 2004 08:32:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPh6F-0003jO-Kn; Mon, 17 May 2004 08:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPh2a-0003B9-RO for ipsec@optimus.ietf.org; Mon, 17 May 2004 08:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17935 for ; Mon, 17 May 2004 08:16:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPh2Z-0007mq-Pi for ipsec@ietf.org; Mon, 17 May 2004 08:16:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPh1n-0007RP-00 for ipsec@ietf.org; Mon, 17 May 2004 08:15:32 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BPgzp-0006kR-00 for ipsec@ietf.org; Mon, 17 May 2004 08:13:29 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4HCDRGQ027678 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 17 May 2004 15:13:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4HCDQoR027675; Mon, 17 May 2004 15:13: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: <16552.44133.542923.965806@fireball.kivinen.iki.fi> Date: Mon, 17 May 2004 15:13:25 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 In-Reply-To: References: <20040511180439.GE8839@thunk.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 11 min X-Total-Time: 95 min Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=NO_EXPERIENCE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > > Which of the following requirements woudl you be willing to live with? > > (You may select more than one): > > > > B) Method #3 (stateful fragment inspection) is a MUST > > D) Method #2 is a MAY, Method #3 is a SHOULD > > E) Method #3 is a SHOULD, May #2 is a MAY What is the difference between D and E. Should the E be "Method #2 is SHOULD and Method #3 is a MAY"? Anyways I can accept method #3 being SHOULD, MAY or even MUST, and Method #2 being MAY. > F) Method #2 is a MAY, and Method #3 is a MAY Which is to say we do not have any preferred method for fragments when using port selectors. I would really like to have one method SHOULD (and that being method #3). > We don't need another MUST or SHOULD to aid interoperability, since > we already have a MUST for #1. We have zero experience with these new > proposals for how to deal with fragmentation. Neither proposal should > be even a SHOULD in 2401bis. Our implementation have been using method #3 since year 1998, so there is some experience with that. I do not know if others do that, but my guess is that there is also other implementations doing same. For the #2 there is no experience, as it do require OPAQUE support, thus there is no way to negotiate it in the IKEv1. The case #3 can be simply be used without any prior negotiation or configuration, and if both ends support it then packets will go through. > It is likely that some vendors will support one and/or the other in > 2401bis deployments, and after they do, we will have a better idea > about whether either is feasible and useful in real implementations; > we can use that experience in changing the requirements levels in > 2401bisbis. Until then, they should both be limited to MAY, > indicating no preference for either from the specification. I can already say that #3 is feasible. If it is useful, that I cannot say, as most of the people do NOT use port selectors at all. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 17 14:01:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08876 for ; Mon, 17 May 2004 14:01:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmCd-0001jk-IA; Mon, 17 May 2004 13:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPm4O-0000a4-W1 for ipsec@optimus.ietf.org; Mon, 17 May 2004 13:38:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07603 for ; Mon, 17 May 2004 13:38:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPm4M-00076t-Sx for ipsec@ietf.org; Mon, 17 May 2004 13:38:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPm3V-0006ka-00 for ipsec@ietf.org; Mon, 17 May 2004 13:37:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BPm2L-0006OV-00 for ipsec@ietf.org; Mon, 17 May 2004 13:36:25 -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 i4HHaJOX088896; Mon, 17 May 2004 10:36:21 -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: Mon, 17 May 2004 10:36:21 -0700 To: "Charlie Kaufman" , From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Proposed Last Call based revisions to IKEv2 Cc: Russ Housley Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 10:50 PM -0700 5/15/04, Charlie Kaufman wrote: >Issue #96, 98 Charlie has proposed changes to align with the fragmentation description in rfc2401bis. I have a different proposition, one that I think the WG may like even better than the one Charlie gave while still achieving the same goal of giving rfc2401bis what it needs. One of the huge problems with IKEv1/2401 is that the specification for how to do things is spread among multiple RFCs. We have cleaned that up to a huge extent in IKEv2/2401bis. However, what Charlie suggests here creates the split again; I think we can nip that in the bud. What I propose is that Charlie only change the following in IKEv2: - In 3.10, add an entry under status-type notify messages: NON-FIRST-FRAGMENTS-ALSO 16395 Used for fragmentation control. See [RFC2401bis] for explanation. - In 3.13.1, eliminate "or port is OPAQUE" in both Start Port and End Port descriptions. - In 3.13.1, just before the text paragraph that starts "The following table lists...", add the following paragraph. Systems that are complying with [RFC2401bis] that wish to indicate "ANY" ports MUST set the start port to 0 and the end port to 65535; note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but not "ANY" ports, MUST set the start port to 65535 and the end port to 0. This way, the IKEv2 document is not specifying any semantics for fragmentation handling, and there is no possibility of disagreement with 2401bis. It also separates out the semantics of OPAQUE and ANY in a way to make it clear that these are 2401bis constructs, not IKEv2 constructs. One concern with using Charlie's text is that it would likely cause the need for another WG Last Call and another IETF Last Call. I believe the above changes could avoid that because the revisions do not specify any new semantics. (Russ, does that sound correct to you?) --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 17 14:15:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10139 for ; Mon, 17 May 2004 14:15:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmZS-0005uG-Pw for ipsec-archive@odin.ietf.org; Mon, 17 May 2004 14:10:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HIAcfo022704 for ipsec-archive@odin.ietf.org; Mon, 17 May 2004 14:10:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmRI-0003Me-Fh for ipsec-web-archive@optimus.ietf.org; Mon, 17 May 2004 14:02:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08952 for ; Mon, 17 May 2004 14:02:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPmRG-0007bj-9Q for ipsec-web-archive@ietf.org; Mon, 17 May 2004 14:02:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmQN-0007IN-00 for ipsec-web-archive@ietf.org; Mon, 17 May 2004 14:01:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPmPo-0006ye-00 for ipsec-web-archive@ietf.org; Mon, 17 May 2004 14:00:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmCd-0001jk-IA; Mon, 17 May 2004 13:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPm4O-0000a4-W1 for ipsec@optimus.ietf.org; Mon, 17 May 2004 13:38:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07603 for ; Mon, 17 May 2004 13:38:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPm4M-00076t-Sx for ipsec@ietf.org; Mon, 17 May 2004 13:38:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPm3V-0006ka-00 for ipsec@ietf.org; Mon, 17 May 2004 13:37:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BPm2L-0006OV-00 for ipsec@ietf.org; Mon, 17 May 2004 13:36:25 -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 i4HHaJOX088896; Mon, 17 May 2004 10:36:21 -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: Mon, 17 May 2004 10:36:21 -0700 To: "Charlie Kaufman" , From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Proposed Last Call based revisions to IKEv2 Cc: Russ Housley Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 10:50 PM -0700 5/15/04, Charlie Kaufman wrote: >Issue #96, 98 Charlie has proposed changes to align with the fragmentation description in rfc2401bis. I have a different proposition, one that I think the WG may like even better than the one Charlie gave while still achieving the same goal of giving rfc2401bis what it needs. One of the huge problems with IKEv1/2401 is that the specification for how to do things is spread among multiple RFCs. We have cleaned that up to a huge extent in IKEv2/2401bis. However, what Charlie suggests here creates the split again; I think we can nip that in the bud. What I propose is that Charlie only change the following in IKEv2: - In 3.10, add an entry under status-type notify messages: NON-FIRST-FRAGMENTS-ALSO 16395 Used for fragmentation control. See [RFC2401bis] for explanation. - In 3.13.1, eliminate "or port is OPAQUE" in both Start Port and End Port descriptions. - In 3.13.1, just before the text paragraph that starts "The following table lists...", add the following paragraph. Systems that are complying with [RFC2401bis] that wish to indicate "ANY" ports MUST set the start port to 0 and the end port to 65535; note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but not "ANY" ports, MUST set the start port to 65535 and the end port to 0. This way, the IKEv2 document is not specifying any semantics for fragmentation handling, and there is no possibility of disagreement with 2401bis. It also separates out the semantics of OPAQUE and ANY in a way to make it clear that these are 2401bis constructs, not IKEv2 constructs. One concern with using Charlie's text is that it would likely cause the need for another WG Last Call and another IETF Last Call. I believe the above changes could avoid that because the revisions do not specify any new semantics. (Russ, does that sound correct to you?) --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 18 14:20:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03436 for ; Tue, 18 May 2004 14:20:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ93P-0003y7-KZ; Tue, 18 May 2004 14:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8pp-000105-6J for ipsec@optimus.ietf.org; Tue, 18 May 2004 13:57:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01565 for ; Tue, 18 May 2004 13:56:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8pm-0003Gw-RE for ipsec@ietf.org; Tue, 18 May 2004 13:56:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8oo-0003EO-00 for ipsec@ietf.org; Tue, 18 May 2004 13:55:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8nq-0003B2-00 for ipsec@ietf.org; Tue, 18 May 2004 13:54:58 -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 i4IHsplE069411 for ; Tue, 18 May 2004 10:54:53 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16552.44133.542923.965806@fireball.kivinen.iki.fi> References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> Date: Tue, 18 May 2004 10:54:52 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,NO_EXPERIENCE autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 3:13 PM +0300 5/17/04, Tero Kivinen wrote: >Anyways I can accept method #3 being SHOULD, MAY or even MUST, and >Method #2 being MAY. Certainly not a MUST; it really isn't needed for interoperability. It is quite conceivable that many systems would only want to work with ANY, and not need either #2 or #3. >Our implementation have been using method #3 since year 1998, so there >is some experience with that. I do not know if others do that, but my >guess is that there is also other implementations doing same. For the >#2 there is no experience, as it do require OPAQUE support, thus there >is no way to negotiate it in the IKEv1. > >The case #3 can be simply be used without any prior negotiation or >configuration, and if both ends support it then packets will go >through. But the negotiation is a pretty important part of #3. I see your point about wanting one of #2 or #3 to be a SHOULD, but I think it is still way too early to prefer one, and I think it's too early to guess that one will work better than the other. It is appropriate when going from Proposed to Draft to change some of the requirements. Maybe leave both of these MAYs for now with the intention of upping one or both to SHOULD when the document advances. >I can already say that #3 is feasible. If it is useful, that I cannot >say, as most of the people do NOT use port selectors at all. A very good reason to wait until there is more experience. I suspect that the new discussion in 2401bis will cause some developers to pay much more attention to this and possibly exposed it more to their customers. The results of that (or the continued lack of interest) will be valuable. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 18 14:42:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04676 for ; Tue, 18 May 2004 14:42:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9Nv-0001XV-3z for ipsec-archive@odin.ietf.org; Tue, 18 May 2004 14:32:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IIWFbe005918 for ipsec-archive@odin.ietf.org; Tue, 18 May 2004 14:32:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9DB-000612-8M for ipsec-web-archive@optimus.ietf.org; Tue, 18 May 2004 14:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03474 for ; Tue, 18 May 2004 14:21:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9D8-00055M-M1 for ipsec-web-archive@ietf.org; Tue, 18 May 2004 14:21:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9CC-00053M-00 for ipsec-web-archive@ietf.org; Tue, 18 May 2004 14:20:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9Br-00051f-00 for ipsec-web-archive@ietf.org; Tue, 18 May 2004 14:19:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ93P-0003y7-KZ; Tue, 18 May 2004 14:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8pp-000105-6J for ipsec@optimus.ietf.org; Tue, 18 May 2004 13:57:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01565 for ; Tue, 18 May 2004 13:56:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8pm-0003Gw-RE for ipsec@ietf.org; Tue, 18 May 2004 13:56:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8oo-0003EO-00 for ipsec@ietf.org; Tue, 18 May 2004 13:55:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8nq-0003B2-00 for ipsec@ietf.org; Tue, 18 May 2004 13:54:58 -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 i4IHsplE069411 for ; Tue, 18 May 2004 10:54:53 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16552.44133.542923.965806@fireball.kivinen.iki.fi> References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> Date: Tue, 18 May 2004 10:54:52 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,NO_EXPERIENCE autolearn=no version=2.60 At 3:13 PM +0300 5/17/04, Tero Kivinen wrote: >Anyways I can accept method #3 being SHOULD, MAY or even MUST, and >Method #2 being MAY. Certainly not a MUST; it really isn't needed for interoperability. It is quite conceivable that many systems would only want to work with ANY, and not need either #2 or #3. >Our implementation have been using method #3 since year 1998, so there >is some experience with that. I do not know if others do that, but my >guess is that there is also other implementations doing same. For the >#2 there is no experience, as it do require OPAQUE support, thus there >is no way to negotiate it in the IKEv1. > >The case #3 can be simply be used without any prior negotiation or >configuration, and if both ends support it then packets will go >through. But the negotiation is a pretty important part of #3. I see your point about wanting one of #2 or #3 to be a SHOULD, but I think it is still way too early to prefer one, and I think it's too early to guess that one will work better than the other. It is appropriate when going from Proposed to Draft to change some of the requirements. Maybe leave both of these MAYs for now with the intention of upping one or both to SHOULD when the document advances. >I can already say that #3 is feasible. If it is useful, that I cannot >say, as most of the people do NOT use port selectors at all. A very good reason to wait until there is more experience. I suspect that the new discussion in 2401bis will cause some developers to pay much more attention to this and possibly exposed it more to their customers. The results of that (or the continued lack of interest) will be valuable. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue May 18 19:46:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28556 for ; Tue, 18 May 2004 19:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQE6y-0006ym-SZ; Tue, 18 May 2004 19:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQE5G-0006b3-6w for ipsec@optimus.ietf.org; Tue, 18 May 2004 19:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27948 for ; Tue, 18 May 2004 19:33:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQE5E-00079f-Gz for ipsec@ietf.org; Tue, 18 May 2004 19:33:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQE4C-00074s-00 for ipsec@ietf.org; Tue, 18 May 2004 19:32:12 -0400 Received: from mail1.panix.com ([166.84.1.72]) by ietf-mx with esmtp (Exim 4.12) id 1BQE3L-0006yH-00 for ipsec@ietf.org; Tue, 18 May 2004 19:31:19 -0400 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 681C448AAF for ; Tue, 18 May 2004 19:31:09 -0400 (EDT) Received: (from tls@localhost) by panix5.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i4INV9527768 for ipsec@ietf.org; Tue, 18 May 2004 19:31:09 -0400 (EDT) Date: Tue, 18 May 2004 19:31:09 -0400 From: Thor Lancelot Simon To: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Message-ID: <20040518233109.GA27517@panix.com> Reply-To: tls@rek.tjls.com References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16552.44133.542923.965806@fireball.kivinen.iki.fi> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , On Mon, May 17, 2004 at 03:13:25PM +0300, Tero Kivinen wrote: > Paul Hoffman / VPNC writes: > > > Which of the following requirements woudl you be willing to live with? > > > (You may select more than one): > > > > > > B) Method #3 (stateful fragment inspection) is a MUST > > > D) Method #2 is a MAY, Method #3 is a SHOULD > > > E) Method #3 is a SHOULD, May #2 is a MAY > > What is the difference between D and E. Should the E be "Method #2 is > SHOULD and Method #3 is a MAY"? > > Anyways I can accept method #3 being SHOULD, MAY or even MUST, and > Method #2 being MAY. > > > F) Method #2 is a MAY, and Method #3 is a MAY > > Which is to say we do not have any preferred method for fragments when > using port selectors. I would really like to have one method SHOULD > (and that being method #3). I concur. We should recommend (or even mandate) something in this area, I believe. Thor _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Tue May 18 19:50:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28734 for ; Tue, 18 May 2004 19:50:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQEKF-0001n6-Ax for ipsec-archive@odin.ietf.org; Tue, 18 May 2004 19:48:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4INmlTO006885 for ipsec-archive@odin.ietf.org; Tue, 18 May 2004 19:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQEIv-0000x0-IT for ipsec-web-archive@optimus.ietf.org; Tue, 18 May 2004 19:47:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28601 for ; Tue, 18 May 2004 19:47:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQEIt-0000Pf-R6 for ipsec-web-archive@ietf.org; Tue, 18 May 2004 19:47:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQEHz-0000Lj-00 for ipsec-web-archive@ietf.org; Tue, 18 May 2004 19:46:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQEHQ-0000Hm-00 for ipsec-web-archive@ietf.org; Tue, 18 May 2004 19:45:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQE6y-0006ym-SZ; Tue, 18 May 2004 19:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQE5G-0006b3-6w for ipsec@optimus.ietf.org; Tue, 18 May 2004 19:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27948 for ; Tue, 18 May 2004 19:33:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQE5E-00079f-Gz for ipsec@ietf.org; Tue, 18 May 2004 19:33:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQE4C-00074s-00 for ipsec@ietf.org; Tue, 18 May 2004 19:32:12 -0400 Received: from mail1.panix.com ([166.84.1.72]) by ietf-mx with esmtp (Exim 4.12) id 1BQE3L-0006yH-00 for ipsec@ietf.org; Tue, 18 May 2004 19:31:19 -0400 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 681C448AAF for ; Tue, 18 May 2004 19:31:09 -0400 (EDT) Received: (from tls@localhost) by panix5.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i4INV9527768 for ipsec@ietf.org; Tue, 18 May 2004 19:31:09 -0400 (EDT) Date: Tue, 18 May 2004 19:31:09 -0400 From: Thor Lancelot Simon To: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Message-ID: <20040518233109.GA27517@panix.com> Reply-To: tls@rek.tjls.com References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16552.44133.542923.965806@fireball.kivinen.iki.fi> User-Agent: Mutt/1.4.2.1i Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, May 17, 2004 at 03:13:25PM +0300, Tero Kivinen wrote: > Paul Hoffman / VPNC writes: > > > Which of the following requirements woudl you be willing to live with? > > > (You may select more than one): > > > > > > B) Method #3 (stateful fragment inspection) is a MUST > > > D) Method #2 is a MAY, Method #3 is a SHOULD > > > E) Method #3 is a SHOULD, May #2 is a MAY > > What is the difference between D and E. Should the E be "Method #2 is > SHOULD and Method #3 is a MAY"? > > Anyways I can accept method #3 being SHOULD, MAY or even MUST, and > Method #2 being MAY. > > > F) Method #2 is a MAY, and Method #3 is a MAY > > Which is to say we do not have any preferred method for fragments when > using port selectors. I would really like to have one method SHOULD > (and that being method #3). I concur. We should recommend (or even mandate) something in this area, I believe. Thor _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed May 19 05:37:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24580 for ; Wed, 19 May 2004 05:37:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN69-0007cM-Mf; Wed, 19 May 2004 05:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQM0B-0007Jy-3D for ipsec@optimus.ietf.org; Wed, 19 May 2004 04:00:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19901 for ; Wed, 19 May 2004 04:00:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQM08-0005O8-F0 for ipsec@ietf.org; Wed, 19 May 2004 04:00:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQLzB-0005H2-00 for ipsec@ietf.org; Wed, 19 May 2004 03:59:34 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BQLyT-0005A8-00 for ipsec@ietf.org; Wed, 19 May 2004 03:58:49 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4J7wmGQ025068 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 May 2004 10:58:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4J7wkLw025065; Wed, 19 May 2004 10:58:46 +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: <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Wed, 19 May 2004 10:58:46 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 In-Reply-To: References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 13 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=NO_EXPERIENCE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > At 3:13 PM +0300 5/17/04, Tero Kivinen wrote: > >Anyways I can accept method #3 being SHOULD, MAY or even MUST, and > >Method #2 being MAY. > > Certainly not a MUST; it really isn't needed for interoperability. It > is quite conceivable that many systems would only want to work with > ANY, and not need either #2 or #3. One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. In the RFC2401 it was SHOULD. I think it should follow the same selection we have here for #2, i.e.. MAY or SHOULD. > >Our implementation have been using method #3 since year 1998, so there > >is some experience with that. I do not know if others do that, but my > >guess is that there is also other implementations doing same. For the > >#2 there is no experience, as it do require OPAQUE support, thus there > >is no way to negotiate it in the IKEv1. > > > >The case #3 can be simply be used without any prior negotiation or > >configuration, and if both ends support it then packets will go > >through. > > But the negotiation is a pretty important part of #3. I see your No, not really. Negotiation is only needed if there is another way to do it, i.e. if the #2 is defined. Int IKEv1 there was no way to use #2, as you could not negotiate OPAQUE, thus there was no other way to get fragmented packets with port selectors through. > point about wanting one of #2 or #3 to be a SHOULD, but I think it is > still way too early to prefer one, and I think it's too early to > guess that one will work better than the other. Might be. I was simply commenting that we do have experience of the statefull inspection case, so if we use running code as an guideline which to make SHOULD, we at least have some running code for the case #3.... > It is appropriate when going from Proposed to Draft to change some of > the requirements. Maybe leave both of these MAYs for now with the > intention of upping one or both to SHOULD when the document advances. No, I do not think we need MAY+ there now... If they are MAYs then they are MAYs, and thats it. Lets make the decision now and then accept that. > >I can already say that #3 is feasible. If it is useful, that I cannot > >say, as most of the people do NOT use port selectors at all. > > A very good reason to wait until there is more experience. I suspect > that the new discussion in 2401bis will cause some developers to pay > much more attention to this and possibly exposed it more to their > customers. The results of that (or the continued lack of interest) > will be valuable. So I assume that your vote would be on both on being MAY? My preferred way would be #3 being SHOULD and #2 being MAY. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Wed May 19 06:02:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26852 for ; Wed, 19 May 2004 06:02:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNk1-0000Ew-Kn for ipsec-archive@odin.ietf.org; Wed, 19 May 2004 05:52:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9q16h000916 for ipsec-archive@odin.ietf.org; Wed, 19 May 2004 05:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNXp-00059m-0k for ipsec-web-archive@optimus.ietf.org; Wed, 19 May 2004 05:39:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24768 for ; Wed, 19 May 2004 05:39:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNXc-0004Vk-Np for ipsec-web-archive@ietf.org; Wed, 19 May 2004 05:39:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNWc-0004HV-00 for ipsec-web-archive@ietf.org; Wed, 19 May 2004 05:38:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQNVe-00041t-00 for ipsec-web-archive@ietf.org; Wed, 19 May 2004 05:37:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN69-0007cM-Mf; Wed, 19 May 2004 05:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQM0B-0007Jy-3D for ipsec@optimus.ietf.org; Wed, 19 May 2004 04:00:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19901 for ; Wed, 19 May 2004 04:00:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQM08-0005O8-F0 for ipsec@ietf.org; Wed, 19 May 2004 04:00:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQLzB-0005H2-00 for ipsec@ietf.org; Wed, 19 May 2004 03:59:34 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BQLyT-0005A8-00 for ipsec@ietf.org; Wed, 19 May 2004 03:58:49 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4J7wmGQ025068 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 May 2004 10:58:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4J7wkLw025065; Wed, 19 May 2004 10:58:46 +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: <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Wed, 19 May 2004 10:58:46 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 In-Reply-To: References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 13 min Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=NO_EXPERIENCE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > At 3:13 PM +0300 5/17/04, Tero Kivinen wrote: > >Anyways I can accept method #3 being SHOULD, MAY or even MUST, and > >Method #2 being MAY. > > Certainly not a MUST; it really isn't needed for interoperability. It > is quite conceivable that many systems would only want to work with > ANY, and not need either #2 or #3. One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. In the RFC2401 it was SHOULD. I think it should follow the same selection we have here for #2, i.e.. MAY or SHOULD. > >Our implementation have been using method #3 since year 1998, so there > >is some experience with that. I do not know if others do that, but my > >guess is that there is also other implementations doing same. For the > >#2 there is no experience, as it do require OPAQUE support, thus there > >is no way to negotiate it in the IKEv1. > > > >The case #3 can be simply be used without any prior negotiation or > >configuration, and if both ends support it then packets will go > >through. > > But the negotiation is a pretty important part of #3. I see your No, not really. Negotiation is only needed if there is another way to do it, i.e. if the #2 is defined. Int IKEv1 there was no way to use #2, as you could not negotiate OPAQUE, thus there was no other way to get fragmented packets with port selectors through. > point about wanting one of #2 or #3 to be a SHOULD, but I think it is > still way too early to prefer one, and I think it's too early to > guess that one will work better than the other. Might be. I was simply commenting that we do have experience of the statefull inspection case, so if we use running code as an guideline which to make SHOULD, we at least have some running code for the case #3.... > It is appropriate when going from Proposed to Draft to change some of > the requirements. Maybe leave both of these MAYs for now with the > intention of upping one or both to SHOULD when the document advances. No, I do not think we need MAY+ there now... If they are MAYs then they are MAYs, and thats it. Lets make the decision now and then accept that. > >I can already say that #3 is feasible. If it is useful, that I cannot > >say, as most of the people do NOT use port selectors at all. > > A very good reason to wait until there is more experience. I suspect > that the new discussion in 2401bis will cause some developers to pay > much more attention to this and possibly exposed it more to their > customers. The results of that (or the continued lack of interest) > will be valuable. So I assume that your vote would be on both on being MAY? My preferred way would be #3 being SHOULD and #2 being MAY. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed May 19 14:49:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00185 for ; Wed, 19 May 2004 14:49:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVn4-0006OX-Pv; Wed, 19 May 2004 14:27:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSd1-0002Q7-Gq for ipsec@optimus.ietf.org; Wed, 19 May 2004 11:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18062 for ; Wed, 19 May 2004 11:05:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQScy-0004FA-UC for ipsec@ietf.org; Wed, 19 May 2004 11:05:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQScG-0004Ay-00 for ipsec@ietf.org; Wed, 19 May 2004 11:04:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BQSbM-00045d-00 for ipsec@ietf.org; Wed, 19 May 2004 11:03:25 -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 i4JF3I55040368; Wed, 19 May 2004 08:03:19 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16555.5046.667046.853895@fireball.kivinen.iki.fi> References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Wed, 19 May 2004 07:56:31 -0700 To: Tero Kivinen From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 10:58 AM +0300 5/19/04, Tero Kivinen wrote: >One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. Then that *needs* to be corrected in the next version of the draft. >So I assume that your vote would be on both on being MAY? Correct. >My preferred way would be #3 being SHOULD and #2 being MAY. That makes some sense too; it's just more adventurous than I would be with this protocol without a lot more support from other vendors. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Wed May 19 15:40:29 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06926 for ; Wed, 19 May 2004 15:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWlJ-0007kc-9c for ipsec-archive@odin.ietf.org; Wed, 19 May 2004 15:29:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJTvIx029792 for ipsec-archive@odin.ietf.org; Wed, 19 May 2004 15:29:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQW9k-0003Mu-B9 for ipsec-web-archive@optimus.ietf.org; Wed, 19 May 2004 14:51:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00338 for ; Wed, 19 May 2004 14:51:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQW9h-0000iF-Gg for ipsec-web-archive@ietf.org; Wed, 19 May 2004 14:51:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQW8t-0000ak-00 for ipsec-web-archive@ietf.org; Wed, 19 May 2004 14:50:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQW80-0000RL-00 for ipsec-web-archive@ietf.org; Wed, 19 May 2004 14:49:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVn4-0006OX-Pv; Wed, 19 May 2004 14:27:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSd1-0002Q7-Gq for ipsec@optimus.ietf.org; Wed, 19 May 2004 11:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18062 for ; Wed, 19 May 2004 11:05:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQScy-0004FA-UC for ipsec@ietf.org; Wed, 19 May 2004 11:05:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQScG-0004Ay-00 for ipsec@ietf.org; Wed, 19 May 2004 11:04:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BQSbM-00045d-00 for ipsec@ietf.org; Wed, 19 May 2004 11:03:25 -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 i4JF3I55040368; Wed, 19 May 2004 08:03:19 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16555.5046.667046.853895@fireball.kivinen.iki.fi> References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Wed, 19 May 2004 07:56:31 -0700 To: Tero Kivinen From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 10:58 AM +0300 5/19/04, Tero Kivinen wrote: >One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. Then that *needs* to be corrected in the next version of the draft. >So I assume that your vote would be on both on being MAY? Correct. >My preferred way would be #3 being SHOULD and #2 being MAY. That makes some sense too; it's just more adventurous than I would be with this protocol without a lot more support from other vendors. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed May 19 18:10:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23823 for ; Wed, 19 May 2004 18:10:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZ4h-0003Tm-7x; Wed, 19 May 2004 17:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYyp-0000fu-OO for ipsec@optimus.ietf.org; Wed, 19 May 2004 17:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21938 for ; Wed, 19 May 2004 17:51:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQYyn-0006uJ-1u for ipsec@ietf.org; Wed, 19 May 2004 17:52:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQYy3-0006mi-00 for ipsec@ietf.org; Wed, 19 May 2004 17:51:16 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BQYx8-0006eR-00 for ipsec@ietf.org; Wed, 19 May 2004 17:50:18 -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 i4JLmso18935 for ; Wed, 19 May 2004 17:48:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4JLllFE017017 for ; Wed, 19 May 2004 17:47:47 -0400 (EDT) Received: from 68-92-64-51.ded.swbell.net(68.92.64.51) by nutshell.tislabs.com via csmap (V6.0) id srcAAADraWnH; Wed, 19 May 04 17:47:45 -0400 Message-ID: <030c01c43dec$3548a1fc$e5474f9a@h5fqn01> From: "Carly Weber" To: Date: Wed, 19 May 2004 16:57:23 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" X-Priority: 3 X-Mailer: PHP X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_20_30,HTML_MESSAGE, HTML_TAG_BALANCE_BODY,HTML_TITLE_EMPTY,MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Can't beat our software prices! Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here


Would you like to stop reciving these? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Wed May 19 18:28:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25167 for ; Wed, 19 May 2004 18:28:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZQC-0007xF-MZ for ipsec-archive@odin.ietf.org; Wed, 19 May 2004 18:20:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JMKK6T030578 for ipsec-archive@odin.ietf.org; Wed, 19 May 2004 18:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZHL-00031O-5W for ipsec-web-archive@optimus.ietf.org; Wed, 19 May 2004 18:11:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23928 for ; Wed, 19 May 2004 18:11:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQZHI-0001X3-BV for ipsec-web-archive@ietf.org; Wed, 19 May 2004 18:11:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQZGL-0001QJ-00 for ipsec-web-archive@ietf.org; Wed, 19 May 2004 18:10:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQZFo-0001KH-00 for ipsec-web-archive@ietf.org; Wed, 19 May 2004 18:09:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZ4h-0003Tm-7x; Wed, 19 May 2004 17:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYyp-0000fu-OO for ipsec@optimus.ietf.org; Wed, 19 May 2004 17:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21938 for ; Wed, 19 May 2004 17:51:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQYyn-0006uJ-1u for ipsec@ietf.org; Wed, 19 May 2004 17:52:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQYy3-0006mi-00 for ipsec@ietf.org; Wed, 19 May 2004 17:51:16 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BQYx8-0006eR-00 for ipsec@ietf.org; Wed, 19 May 2004 17:50:18 -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 i4JLmso18935 for ; Wed, 19 May 2004 17:48:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4JLllFE017017 for ; Wed, 19 May 2004 17:47:47 -0400 (EDT) Received: from 68-92-64-51.ded.swbell.net(68.92.64.51) by nutshell.tislabs.com via csmap (V6.0) id srcAAADraWnH; Wed, 19 May 04 17:47:45 -0400 Message-ID: <030c01c43dec$3548a1fc$e5474f9a@h5fqn01> From: "Carly Weber" To: Date: Wed, 19 May 2004 16:57:23 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" X-Priority: 3 X-Mailer: PHP Subject: [Ipsec] Can't beat our software prices! Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_20_30,HTML_MESSAGE, HTML_TAG_BALANCE_BODY,HTML_TITLE_EMPTY,MIME_HTML_ONLY autolearn=no version=2.60 TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here


Would you like to stop reciving these? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 20 11:44:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25424 for ; Thu, 20 May 2004 11:44:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp7d-0004cZ-CB; Thu, 20 May 2004 11:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQoRc-0004uc-Iy for ipsec@optimus.ietf.org; Thu, 20 May 2004 10:22:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19525 for ; Thu, 20 May 2004 10:22:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQoRa-0004sJ-9a for ipsec@ietf.org; Thu, 20 May 2004 10:22:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQoQj-0004fX-00 for ipsec@ietf.org; Thu, 20 May 2004 10:21:54 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BQoQC-0004RF-00 for ipsec@ietf.org; Thu, 20 May 2004 10:21:20 -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 i4KEKj7b022696; Thu, 20 May 2004 10:20:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Thu, 20 May 2004 10:18:50 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: Tero Kivinen , ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 7:56 AM -0700 5/19/04, Paul Hoffman / VPNC wrote: >At 10:58 AM +0300 5/19/04, Tero Kivinen wrote: >>One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. > >Then that *needs* to be corrected in the next version of the draft. Support for the selector type in the SPD is trivial, and if we mandate support for OPAQUE now, then we're set for later elevation of one of these options to SHOULD from MAY, for example. > >>So I assume that your vote would be on both on being MAY? > >Correct. > >>My preferred way would be #3 being SHOULD and #2 being MAY. > >That makes some sense too; it's just more adventurous than I would >be with this protocol without a lot more support from other vendors. I agree with Tero that #3 as SHOULD is appropriate. My only concern re #3, as Ted noted earlier, is that it imposes an unacceptable burden on high speed implementations. Thus, if #3 is SHOULD, then I think it would be legitimate for such implementations to not support it (consistent with the interpretation of SHOULD). I would like these implementations to support #2 in that case. A statement that an implementation SHOULD support either #2 or #3 might be one way of expressing this notion. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 20 12:33:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29721 for ; Thu, 20 May 2004 12:33:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQq2r-0007XW-6X for ipsec-archive@odin.ietf.org; Thu, 20 May 2004 12:05:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KG5LwM028983 for ipsec-archive@odin.ietf.org; Thu, 20 May 2004 12:05:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQplQ-0001MY-3o for ipsec-web-archive@optimus.ietf.org; Thu, 20 May 2004 11:47:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25785 for ; Thu, 20 May 2004 11:47:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQplP-0006ii-06 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 11:47:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpjH-0006Nl-00 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 11:45:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQphp-00069d-00 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 11:43:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp7d-0004cZ-CB; Thu, 20 May 2004 11:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQoRc-0004uc-Iy for ipsec@optimus.ietf.org; Thu, 20 May 2004 10:22:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19525 for ; Thu, 20 May 2004 10:22:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQoRa-0004sJ-9a for ipsec@ietf.org; Thu, 20 May 2004 10:22:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQoQj-0004fX-00 for ipsec@ietf.org; Thu, 20 May 2004 10:21:54 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BQoQC-0004RF-00 for ipsec@ietf.org; Thu, 20 May 2004 10:21:20 -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 i4KEKj7b022696; Thu, 20 May 2004 10:20:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Thu, 20 May 2004 10:18:50 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: Tero Kivinen , ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 7:56 AM -0700 5/19/04, Paul Hoffman / VPNC wrote: >At 10:58 AM +0300 5/19/04, Tero Kivinen wrote: >>One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. > >Then that *needs* to be corrected in the next version of the draft. Support for the selector type in the SPD is trivial, and if we mandate support for OPAQUE now, then we're set for later elevation of one of these options to SHOULD from MAY, for example. > >>So I assume that your vote would be on both on being MAY? > >Correct. > >>My preferred way would be #3 being SHOULD and #2 being MAY. > >That makes some sense too; it's just more adventurous than I would >be with this protocol without a lot more support from other vendors. I agree with Tero that #3 as SHOULD is appropriate. My only concern re #3, as Ted noted earlier, is that it imposes an unacceptable burden on high speed implementations. Thus, if #3 is SHOULD, then I think it would be legitimate for such implementations to not support it (consistent with the interpretation of SHOULD). I would like these implementations to support #2 in that case. A statement that an implementation SHOULD support either #2 or #3 might be one way of expressing this notion. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 20 13:29:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04161 for ; Thu, 20 May 2004 13:29:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrAO-0007fq-32; Thu, 20 May 2004 13:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqxP-0003LR-4I for ipsec@optimus.ietf.org; Thu, 20 May 2004 13:03:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02546 for ; Thu, 20 May 2004 13:03:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqxN-0006mR-6C for ipsec@ietf.org; Thu, 20 May 2004 13:03:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqwQ-0006hM-00 for ipsec@ietf.org; Thu, 20 May 2004 13:02:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BQqva-0006ax-00 for ipsec@ietf.org; Thu, 20 May 2004 13:01: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 i4KH1g1m093034; Thu, 20 May 2004 10:01: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: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Thu, 20 May 2004 10:01:41 -0700 To: Stephen Kent From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: Tero Kivinen , ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 10:18 AM -0400 5/20/04, Stephen Kent wrote: >At 7:56 AM -0700 5/19/04, Paul Hoffman / VPNC wrote: >>At 10:58 AM +0300 5/19/04, Tero Kivinen wrote: >>>One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. >> >>Then that *needs* to be corrected in the next version of the draft. > >Support for the selector type in the SPD is trivial, and if we >mandate support for OPAQUE now, then we're set for later elevation >of one of these options to SHOULD from MAY, for example. True, but I worry about mandating the ability for a 2401bis system to support a selector type when it doesn't support the mechanics that goes with the selector. It gets tricky in 2401bis because the new fragmentation ideas are spread throughout the document. We might just have to live with that. >>>My preferred way would be #3 being SHOULD and #2 being MAY. >> >>That makes some sense too; it's just more adventurous than I would >>be with this protocol without a lot more support from other vendors. > >I agree with Tero that #3 as SHOULD is appropriate. My only concern >re #3, as Ted noted earlier, is that it imposes an unacceptable >burden on high speed implementations. Thus, if #3 is SHOULD, then I >think it would be legitimate for such implementations to not support >it (consistent with the interpretation of SHOULD). Agree. Not following a SHOULD because you know that you won't be able to consistently figure out where the fragment would go is perfectly legitimate. > I would like these implementations to support #2 in that case. A >statement that an implementation SHOULD support either #2 or #3 >might be one way of expressing this notion. A very good suggestion. The paragraph currently at the end of page 49 could be changed from: To address the above requirements, three approaches have been defined: To: To address the above requirements, three approaches have been defined. Implementations MUST support method #1 below, and SHOULD support method #2 or method #3 (or both). Editorial suggestion: breaking out the three proposals as subsections (7.1, 7.2, 7.3) would make it easier to read, particularly if you add more text to them. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 20 13:50:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06535 for ; Thu, 20 May 2004 13:50:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrcq-0006Rl-Ed for ipsec-archive@odin.ietf.org; Thu, 20 May 2004 13:46:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KHkaaj024782 for ipsec-archive@odin.ietf.org; Thu, 20 May 2004 13:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrQx-0003YX-P1 for ipsec-web-archive@optimus.ietf.org; Thu, 20 May 2004 13:34:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05138 for ; Thu, 20 May 2004 13:34:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQrQv-0002Kk-J6 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 13:34:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQrOf-0001tp-00 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 13:31:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQrLO-0001Rf-00 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 13:28:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrAO-0007fq-32; Thu, 20 May 2004 13:17:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqxP-0003LR-4I for ipsec@optimus.ietf.org; Thu, 20 May 2004 13:03:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02546 for ; Thu, 20 May 2004 13:03:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqxN-0006mR-6C for ipsec@ietf.org; Thu, 20 May 2004 13:03:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqwQ-0006hM-00 for ipsec@ietf.org; Thu, 20 May 2004 13:02:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BQqva-0006ax-00 for ipsec@ietf.org; Thu, 20 May 2004 13:01: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 i4KH1g1m093034; Thu, 20 May 2004 10:01: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: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Thu, 20 May 2004 10:01:41 -0700 To: Stephen Kent From: Paul Hoffman / VPNC Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: Tero Kivinen , ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 10:18 AM -0400 5/20/04, Stephen Kent wrote: >At 7:56 AM -0700 5/19/04, Paul Hoffman / VPNC wrote: >>At 10:58 AM +0300 5/19/04, Tero Kivinen wrote: >>>One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. >> >>Then that *needs* to be corrected in the next version of the draft. > >Support for the selector type in the SPD is trivial, and if we >mandate support for OPAQUE now, then we're set for later elevation >of one of these options to SHOULD from MAY, for example. True, but I worry about mandating the ability for a 2401bis system to support a selector type when it doesn't support the mechanics that goes with the selector. It gets tricky in 2401bis because the new fragmentation ideas are spread throughout the document. We might just have to live with that. >>>My preferred way would be #3 being SHOULD and #2 being MAY. >> >>That makes some sense too; it's just more adventurous than I would >>be with this protocol without a lot more support from other vendors. > >I agree with Tero that #3 as SHOULD is appropriate. My only concern >re #3, as Ted noted earlier, is that it imposes an unacceptable >burden on high speed implementations. Thus, if #3 is SHOULD, then I >think it would be legitimate for such implementations to not support >it (consistent with the interpretation of SHOULD). Agree. Not following a SHOULD because you know that you won't be able to consistently figure out where the fragment would go is perfectly legitimate. > I would like these implementations to support #2 in that case. A >statement that an implementation SHOULD support either #2 or #3 >might be one way of expressing this notion. A very good suggestion. The paragraph currently at the end of page 49 could be changed from: To address the above requirements, three approaches have been defined: To: To address the above requirements, three approaches have been defined. Implementations MUST support method #1 below, and SHOULD support method #2 or method #3 (or both). Editorial suggestion: breaking out the three proposals as subsections (7.1, 7.2, 7.3) would make it easier to read, particularly if you add more text to them. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 20 14:56:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11684 for ; Thu, 20 May 2004 14:56:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsUi-0005lm-9z; Thu, 20 May 2004 14:42:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsOT-0001mY-KQ for ipsec@optimus.ietf.org; Thu, 20 May 2004 14:35:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10139 for ; Thu, 20 May 2004 14:35:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQsOQ-0000rG-Rj for ipsec@ietf.org; Thu, 20 May 2004 14:35:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsNS-0000nA-00 for ipsec@ietf.org; Thu, 20 May 2004 14:34:46 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BQsMb-0000hc-00 for ipsec@ietf.org; Thu, 20 May 2004 14:33:53 -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 i4KIXI7Z007304; Thu, 20 May 2004 14:33:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Thu, 20 May 2004 13:33:47 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 10:01 AM -0700 5/20/04, Paul Hoffman / VPNC wrote: >At 10:18 AM -0400 5/20/04, Stephen Kent wrote: >>At 7:56 AM -0700 5/19/04, Paul Hoffman / VPNC wrote: >>>At 10:58 AM +0300 5/19/04, Tero Kivinen wrote: >>>>One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. >>> >>>Then that *needs* to be corrected in the next version of the draft. >> >>Support for the selector type in the SPD is trivial, and if we >>mandate support for OPAQUE now, then we're set for later elevation >>of one of these options to SHOULD from MAY, for example. > >True, but I worry about mandating the ability for a 2401bis system >to support a selector type when it doesn't support the mechanics >that goes with the selector. It gets tricky in 2401bis because the >new fragmentation ideas are spread throughout the document. We might >just have to live with that. I appreciate the concern. We are working on the next rev and found another place where OPAQUE seems appropriate (not for fragmentation support), which would be another reason to include it, if the WG agrees with the added material that refers to OPAQUE. > >>>>My preferred way would be #3 being SHOULD and #2 being MAY. >>> >>>That makes some sense too; it's just more adventurous than I would >>>be with this protocol without a lot more support from other >>>vendors. >> >>I agree with Tero that #3 as SHOULD is appropriate. My only concern >>re #3, as Ted noted earlier, is that it imposes an unacceptable >>burden on high speed implementations. Thus, if #3 is SHOULD, then I >>think it would be legitimate for such implementations to not >>support it (consistent with the interpretation of SHOULD). > >Agree. Not following a SHOULD because you know that you won't be >able to consistently figure out where the fragment would go is >perfectly legitimate. I'm always encouraged when we agree :-) > >> I would like these implementations to support #2 in that case. A >>statement that an implementation SHOULD support either #2 or #3 >>might be one way of expressing this notion. > >A very good suggestion. The paragraph currently at the end of page >49 could be changed from: > To address the above requirements, three approaches have been > defined: >To: > To address the above requirements, three approaches have been > defined. Implementations MUST support method #1 below, and SHOULD > support method #2 or method #3 (or both). again, great! >Editorial suggestion: breaking out the three proposals as >subsections (7.1, 7.2, 7.3) would make it easier to read, >particularly if you add more text to them. > Thanks for the suggestions, Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 20 15:08:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12869 for ; Thu, 20 May 2004 15:08:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQspi-00071o-Oc for ipsec-archive@odin.ietf.org; Thu, 20 May 2004 15:03:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KJ3wWg027007 for ipsec-archive@odin.ietf.org; Thu, 20 May 2004 15:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsk4-00018r-Qj for ipsec-web-archive@optimus.ietf.org; Thu, 20 May 2004 14:58:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11860 for ; Thu, 20 May 2004 14:58:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQsk2-0002rY-1p for ipsec-web-archive@ietf.org; Thu, 20 May 2004 14:58:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsjB-0002oK-00 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 14:57:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQsiD-0002kk-00 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 14:56:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsUi-0005lm-9z; Thu, 20 May 2004 14:42:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsOT-0001mY-KQ for ipsec@optimus.ietf.org; Thu, 20 May 2004 14:35:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10139 for ; Thu, 20 May 2004 14:35:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQsOQ-0000rG-Rj for ipsec@ietf.org; Thu, 20 May 2004 14:35:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQsNS-0000nA-00 for ipsec@ietf.org; Thu, 20 May 2004 14:34:46 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BQsMb-0000hc-00 for ipsec@ietf.org; Thu, 20 May 2004 14:33:53 -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 i4KIXI7Z007304; Thu, 20 May 2004 14:33:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> Date: Thu, 20 May 2004 13:33:47 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 Cc: ipsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 10:01 AM -0700 5/20/04, Paul Hoffman / VPNC wrote: >At 10:18 AM -0400 5/20/04, Stephen Kent wrote: >>At 7:56 AM -0700 5/19/04, Paul Hoffman / VPNC wrote: >>>At 10:58 AM +0300 5/19/04, Tero Kivinen wrote: >>>>One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. >>> >>>Then that *needs* to be corrected in the next version of the draft. >> >>Support for the selector type in the SPD is trivial, and if we >>mandate support for OPAQUE now, then we're set for later elevation >>of one of these options to SHOULD from MAY, for example. > >True, but I worry about mandating the ability for a 2401bis system >to support a selector type when it doesn't support the mechanics >that goes with the selector. It gets tricky in 2401bis because the >new fragmentation ideas are spread throughout the document. We might >just have to live with that. I appreciate the concern. We are working on the next rev and found another place where OPAQUE seems appropriate (not for fragmentation support), which would be another reason to include it, if the WG agrees with the added material that refers to OPAQUE. > >>>>My preferred way would be #3 being SHOULD and #2 being MAY. >>> >>>That makes some sense too; it's just more adventurous than I would >>>be with this protocol without a lot more support from other >>>vendors. >> >>I agree with Tero that #3 as SHOULD is appropriate. My only concern >>re #3, as Ted noted earlier, is that it imposes an unacceptable >>burden on high speed implementations. Thus, if #3 is SHOULD, then I >>think it would be legitimate for such implementations to not >>support it (consistent with the interpretation of SHOULD). > >Agree. Not following a SHOULD because you know that you won't be >able to consistently figure out where the fragment would go is >perfectly legitimate. I'm always encouraged when we agree :-) > >> I would like these implementations to support #2 in that case. A >>statement that an implementation SHOULD support either #2 or #3 >>might be one way of expressing this notion. > >A very good suggestion. The paragraph currently at the end of page >49 could be changed from: > To address the above requirements, three approaches have been > defined: >To: > To address the above requirements, three approaches have been > defined. Implementations MUST support method #1 below, and SHOULD > support method #2 or method #3 (or both). again, great! >Editorial suggestion: breaking out the three proposals as >subsections (7.1, 7.2, 7.3) would make it easier to read, >particularly if you add more text to them. > Thanks for the suggestions, Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 20 17:53:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28891 for ; Thu, 20 May 2004 17:53:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvKo-0003uw-SS; Thu, 20 May 2004 17:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQv8Q-0006uv-5i for ipsec@optimus.ietf.org; Thu, 20 May 2004 17:31:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27194 for ; Thu, 20 May 2004 17:31:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQv8N-0001bz-NP for ipsec@ietf.org; Thu, 20 May 2004 17:31:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQv5x-0001CE-00 for ipsec@ietf.org; Thu, 20 May 2004 17:28:54 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BQv1o-0000gT-00 for ipsec@ietf.org; Thu, 20 May 2004 17:24:37 -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 i4KLN8o12872 for ; Thu, 20 May 2004 17:23:08 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4KLM4T2026482 for ; Thu, 20 May 2004 17:22:04 -0400 (EDT) Received: from unknown(140.239.227.29) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAKaWRZ; Thu, 20 May 04 17:22:03 -0400 Received: from m6b9536d0.tmodns.net ([208.54.149.107] helo=thunk.org ident=Debian-exim) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BQuw6-0003g0-00; Thu, 20 May 2004 17:18:42 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1BQuw4-0003el-2t; Thu, 20 May 2004 17:18:40 -0400 To: Russ Housley cc: Barbara Fraser , "Theodore Ts'o" , "Angelos D. Keromytis" , kivinen@ssh.fi, Steve Bellovin , ipsec@lists.tislabs.com From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Thu, 20 May 2004 17:18:40 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] (no subject) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi Russ, After a working-group last call, the following document is ready to be sent to you for IETF-wide last call: draft-ietf-ipsec-esp-ah-algorithms-01.txt It is a peer to the ikev2 algorithms document and the crypto suites UI, but describes the crypto algorithms requirements for AH and ESP. We would appreciate it if you would put them in your queue for AD review, and update the IETF status tracker appropriately. Many thanks, - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Thu May 20 18:02:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29563 for ; Thu, 20 May 2004 18:02:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvau-0002Dy-M8 for ipsec-archive@odin.ietf.org; Thu, 20 May 2004 18:00:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KM0qkM008538 for ipsec-archive@odin.ietf.org; Thu, 20 May 2004 18:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvUJ-0008Af-2u for ipsec-web-archive@optimus.ietf.org; Thu, 20 May 2004 17:54:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28929 for ; Thu, 20 May 2004 17:53:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQvUG-0003Yn-H7 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 17:54:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvTL-0003Vv-00 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 17:53:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQvT7-0003TI-00 for ipsec-web-archive@ietf.org; Thu, 20 May 2004 17:52:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvKo-0003uw-SS; Thu, 20 May 2004 17:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQv8Q-0006uv-5i for ipsec@optimus.ietf.org; Thu, 20 May 2004 17:31:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27194 for ; Thu, 20 May 2004 17:31:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQv8N-0001bz-NP for ipsec@ietf.org; Thu, 20 May 2004 17:31:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQv5x-0001CE-00 for ipsec@ietf.org; Thu, 20 May 2004 17:28:54 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BQv1o-0000gT-00 for ipsec@ietf.org; Thu, 20 May 2004 17:24:37 -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 i4KLN8o12872 for ; Thu, 20 May 2004 17:23:08 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4KLM4T2026482 for ; Thu, 20 May 2004 17:22:04 -0400 (EDT) Received: from unknown(140.239.227.29) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAKaWRZ; Thu, 20 May 04 17:22:03 -0400 Received: from m6b9536d0.tmodns.net ([208.54.149.107] helo=thunk.org ident=Debian-exim) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BQuw6-0003g0-00; Thu, 20 May 2004 17:18:42 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1BQuw4-0003el-2t; Thu, 20 May 2004 17:18:40 -0400 To: Russ Housley cc: Barbara Fraser , "Theodore Ts'o" , "Angelos D. Keromytis" , kivinen@ssh.fi, Steve Bellovin , ipsec@lists.tislabs.com From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Thu, 20 May 2004 17:18:40 -0400 Subject: [Ipsec] (no subject) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Russ, After a working-group last call, the following document is ready to be sent to you for IETF-wide last call: draft-ietf-ipsec-esp-ah-algorithms-01.txt It is a peer to the ikev2 algorithms document and the crypto suites UI, but describes the crypto algorithms requirements for AH and ESP. We would appreciate it if you would put them in your queue for AD review, and update the IETF status tracker appropriately. Many thanks, - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 21 06:49:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23201 for ; Fri, 21 May 2004 06:49:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7Rb-0000Bf-Ui; Fri, 21 May 2004 06:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7GL-0005jd-Vi for ipsec@optimus.ietf.org; Fri, 21 May 2004 06:28:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21994 for ; Fri, 21 May 2004 06:28:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7GH-00011i-W8 for ipsec@ietf.org; Fri, 21 May 2004 06:28:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7DZ-0000gn-00 for ipsec@ietf.org; Fri, 21 May 2004 06:27:22 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BR7D6-0000Wa-00 for ipsec@ietf.org; Fri, 21 May 2004 06:25:04 -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 i4LANao26200 for ; Fri, 21 May 2004 06:23:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4LA2RpA006690 for ; Fri, 21 May 2004 06:02:27 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8xaOcn; Fri, 21 May 04 06:02:19 -0400 Date: Fri, 21 May 2004 11:10:15 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yadmxacokwztjonqnagm" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Notification Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------yadmxacokwztjonqnagm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------yadmxacokwztjonqnagm Content-Type: text/html; name="You_will_answer_to_me.hta.htm" Content-Disposition: attachment; filename="You_will_answer_to_me.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: You_will_answer_to_me.hta
Virus name: W32/Bagle.aa@MM!vbs

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

----------yadmxacokwztjonqnagm-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 21 07:01:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23789 for ; Fri, 21 May 2004 07:01:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7iJ-0005EM-Mc for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 06:57:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LAvJAS020107 for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 06:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7br-0003iD-Ej for ipsec-web-archive@optimus.ietf.org; Fri, 21 May 2004 06:50:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23280 for ; Fri, 21 May 2004 06:50:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7bn-0005Ad-Bt for ipsec-web-archive@ietf.org; Fri, 21 May 2004 06:50:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7b2-0004zF-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 06:49:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR7aQ-0004ma-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 06:49:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7Rb-0000Bf-Ui; Fri, 21 May 2004 06:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7GL-0005jd-Vi for ipsec@optimus.ietf.org; Fri, 21 May 2004 06:28:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21994 for ; Fri, 21 May 2004 06:28:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7GH-00011i-W8 for ipsec@ietf.org; Fri, 21 May 2004 06:28:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7DZ-0000gn-00 for ipsec@ietf.org; Fri, 21 May 2004 06:27:22 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BR7D6-0000Wa-00 for ipsec@ietf.org; Fri, 21 May 2004 06:25:04 -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 i4LANao26200 for ; Fri, 21 May 2004 06:23:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4LA2RpA006690 for ; Fri, 21 May 2004 06:02:27 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8xaOcn; Fri, 21 May 04 06:02:19 -0400 Date: Fri, 21 May 2004 11:10:15 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yadmxacokwztjonqnagm" Subject: [Ipsec] Notification Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------yadmxacokwztjonqnagm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------yadmxacokwztjonqnagm Content-Type: text/html; name="You_will_answer_to_me.hta.htm" Content-Disposition: attachment; filename="You_will_answer_to_me.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: You_will_answer_to_me.hta
Virus name: W32/Bagle.aa@MM!vbs

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

----------yadmxacokwztjonqnagm-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 21 10:34:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05452 for ; Fri, 21 May 2004 10:34:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAuR-00085M-3m; Fri, 21 May 2004 10:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAeY-0001P2-HV for ipsec@optimus.ietf.org; Fri, 21 May 2004 10:05:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02364 for ; Fri, 21 May 2004 10:05:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRAeV-0003v5-Gc for ipsec@ietf.org; Fri, 21 May 2004 10:05:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRAdZ-0003j7-00 for ipsec@ietf.org; Fri, 21 May 2004 10:04:38 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BRAcm-0003Xh-00 for ipsec@ietf.org; Fri, 21 May 2004 10:03:48 -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 i4LE2Lo21388 for ; Fri, 21 May 2004 10:02:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4LE1Fvj009323 for ; Fri, 21 May 2004 10:01:15 -0400 (EDT) Received: from node-d-4c3a.a2000.nl(62.195.76.58) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHEaGls; Fri, 21 May 04 10:01:11 -0400 Date: Fri, 21 May 2004 15:03:47 +0000 To: "Ipsec" From: "Fukuda" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ujmljuskeofdluylvash" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Protected message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------ujmljuskeofdluylvash Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ujmljuskeofdluylvash Content-Type: text/html; name="You_will_answer_to_me.exe.htm" Content-Disposition: attachment; filename="You_will_answer_to_me.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: You_will_answer_to_me.exe
Virus name: W32/Bagle.aa@MM

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

----------ujmljuskeofdluylvash-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 21 10:46:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06475 for ; Fri, 21 May 2004 10:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRBGD-0000EM-It for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 10:44:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LEiX3I000887 for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 10:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRB7w-000622-37 for ipsec-web-archive@optimus.ietf.org; Fri, 21 May 2004 10:36:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05642 for ; Fri, 21 May 2004 10:35:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRB7t-0002yr-IL for ipsec-web-archive@ietf.org; Fri, 21 May 2004 10:35:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRB78-0002kT-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 10:35:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRB6J-0002Uo-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 10:34:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAuR-00085M-3m; Fri, 21 May 2004 10:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAeY-0001P2-HV for ipsec@optimus.ietf.org; Fri, 21 May 2004 10:05:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02364 for ; Fri, 21 May 2004 10:05:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRAeV-0003v5-Gc for ipsec@ietf.org; Fri, 21 May 2004 10:05:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRAdZ-0003j7-00 for ipsec@ietf.org; Fri, 21 May 2004 10:04:38 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BRAcm-0003Xh-00 for ipsec@ietf.org; Fri, 21 May 2004 10:03:48 -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 i4LE2Lo21388 for ; Fri, 21 May 2004 10:02:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4LE1Fvj009323 for ; Fri, 21 May 2004 10:01:15 -0400 (EDT) Received: from node-d-4c3a.a2000.nl(62.195.76.58) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHEaGls; Fri, 21 May 04 10:01:11 -0400 Date: Fri, 21 May 2004 15:03:47 +0000 To: "Ipsec" From: "Fukuda" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ujmljuskeofdluylvash" Subject: [Ipsec] RE: Protected message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------ujmljuskeofdluylvash Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ujmljuskeofdluylvash Content-Type: text/html; name="You_will_answer_to_me.exe.htm" Content-Disposition: attachment; filename="You_will_answer_to_me.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: You_will_answer_to_me.exe
Virus name: W32/Bagle.aa@MM

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

----------ujmljuskeofdluylvash-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 21 13:58:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18413 for ; Fri, 21 May 2004 13:58:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRE5u-00050l-9h; Fri, 21 May 2004 13:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRE0b-0003i2-5L for ipsec@optimus.ietf.org; Fri, 21 May 2004 13:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17431 for ; Fri, 21 May 2004 13:40:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRE0Y-00075x-W2 for ipsec@ietf.org; Fri, 21 May 2004 13:40:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRDzd-000736-00 for ipsec@ietf.org; Fri, 21 May 2004 13:39:37 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BRDzB-00070K-00 for ipsec@ietf.org; Fri, 21 May 2004 13:39:09 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 10:38:25 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 May 2004 10:38:38 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 10:38:36 -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: Fri, 21 May 2004 10:38:24 -0700 Message-ID: Thread-Topic: OCSP in IKEv2 thread-index: AcQ939DRQtJCEpy/S92C7bKecDXFswBeED2g From: "Charlie Kaufman" To: Cc: "Michael Myers" X-OriginalArrivalTime: 21 May 2004 17:38:36.0912 (UTC) FILETIME=[72385F00:01C43F5A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] RE: OCSP in IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I agree there will be problems with sizes if people try to pass CRLs as part of the IKE negotiation because CRLs tend to be large and IKE runs over UDP. Adding support to IKEv2 for OCSP is plausible, though I believe it is too late in the process for this big a change in this version. Support for OCSP would likely change the number of messages in the IKEv2 exchange. Longer term I also believe this is a bad idea, but for a different reason. Passing certificates 'in band' in IKE makes sense because they are not reliably accessible by any standardized protocol. Both CRL fetching and OCSP are designed to run over IP (not embedded in another protocol), and so I believe it would be better to use those protocols directly rather than taking them apart and reassembling them inside IPsec. There will be occasions when either the CRL or the OCSP server will only be accessible to an endpoint over an IPsec SA, which introduces a chicken and egg problem. In my opinion, the lesser hack would be allow an IPsec SA to come up with limited connectivity without the CRL or OCSP verification, where the connectivity is limited to that required to fetch the CRL or talk to the OCSP server. I'm sure others would violently disagree with my taste on this matter. But in any case, it seems like a debate better conducted in the PKI4IPSEC working group. --Charlie Kaufman -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Wednesday, May 19, 2004 1:24 PM To: ipsec@ietf.org Subject: OCSP in IKEv2 Charlie, Recent discussions in the PKI4IPSEC working group exposed a disconnect between IKE's specification of CRLs and their utility given likely CRL size. Towards in-band alternatives, OCSP as developed by PKIX and defined by RFC 2560 is a viable option for IKE in-band signaling of certificate revocation status. OCSP did not exist as an RFC when IKE was originally drafted; it was still an I-D at that stage of IKE's development. Its absence in IKE's original specification is thus understandable. But OCSP does now exist as an alternative to CRLs. Per a recent PKIX poll, there are something like eight independent implementations of OCSP. I strongly encourage amendment of IKEv2 to accommodate OCSP. TLS has already done so, as has the OWA community. Why not IPSEC? I realize this notice is probably too late for -13 but might consensus could be formed for inclusion in -14 of IKEv2? Michael Myers _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 21 14:10:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18951 for ; Fri, 21 May 2004 14:10:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREK1-00089w-EE for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 14:00:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LI0eRS031360 for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 14:00:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREJ3-0007np-IP for ipsec-web-archive@optimus.ietf.org; Fri, 21 May 2004 13:59:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18473 for ; Fri, 21 May 2004 13:59:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREJ1-0000i0-60 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 13:59:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREI5-0000ek-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 13:58:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BREHh-0000bV-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 13:58:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRE5u-00050l-9h; Fri, 21 May 2004 13:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRE0b-0003i2-5L for ipsec@optimus.ietf.org; Fri, 21 May 2004 13:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17431 for ; Fri, 21 May 2004 13:40:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRE0Y-00075x-W2 for ipsec@ietf.org; Fri, 21 May 2004 13:40:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRDzd-000736-00 for ipsec@ietf.org; Fri, 21 May 2004 13:39:37 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BRDzB-00070K-00 for ipsec@ietf.org; Fri, 21 May 2004 13:39:09 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 10:38:25 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 May 2004 10:38:38 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 10:38:36 -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: Fri, 21 May 2004 10:38:24 -0700 Message-ID: Thread-Topic: OCSP in IKEv2 thread-index: AcQ939DRQtJCEpy/S92C7bKecDXFswBeED2g From: "Charlie Kaufman" To: Cc: "Michael Myers" X-OriginalArrivalTime: 21 May 2004 17:38:36.0912 (UTC) FILETIME=[72385F00:01C43F5A] Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] RE: OCSP in IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I agree there will be problems with sizes if people try to pass CRLs as part of the IKE negotiation because CRLs tend to be large and IKE runs over UDP. Adding support to IKEv2 for OCSP is plausible, though I believe it is too late in the process for this big a change in this version. Support for OCSP would likely change the number of messages in the IKEv2 exchange. Longer term I also believe this is a bad idea, but for a different reason. Passing certificates 'in band' in IKE makes sense because they are not reliably accessible by any standardized protocol. Both CRL fetching and OCSP are designed to run over IP (not embedded in another protocol), and so I believe it would be better to use those protocols directly rather than taking them apart and reassembling them inside IPsec. There will be occasions when either the CRL or the OCSP server will only be accessible to an endpoint over an IPsec SA, which introduces a chicken and egg problem. In my opinion, the lesser hack would be allow an IPsec SA to come up with limited connectivity without the CRL or OCSP verification, where the connectivity is limited to that required to fetch the CRL or talk to the OCSP server. I'm sure others would violently disagree with my taste on this matter. But in any case, it seems like a debate better conducted in the PKI4IPSEC working group. --Charlie Kaufman -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Wednesday, May 19, 2004 1:24 PM To: ipsec@ietf.org Subject: OCSP in IKEv2 Charlie, Recent discussions in the PKI4IPSEC working group exposed a disconnect between IKE's specification of CRLs and their utility given likely CRL size. Towards in-band alternatives, OCSP as developed by PKIX and defined by RFC 2560 is a viable option for IKE in-band signaling of certificate revocation status. OCSP did not exist as an RFC when IKE was originally drafted; it was still an I-D at that stage of IKE's development. Its absence in IKE's original specification is thus understandable. But OCSP does now exist as an alternative to CRLs. Per a recent PKIX poll, there are something like eight independent implementations of OCSP. I strongly encourage amendment of IKEv2 to accommodate OCSP. TLS has already done so, as has the OWA community. Why not IPSEC? I realize this notice is probably too late for -13 but might consensus could be formed for inclusion in -14 of IKEv2? Michael Myers _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 21 14:22:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19498 for ; Fri, 21 May 2004 14:22:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREV0-0002V1-J7; Fri, 21 May 2004 14:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREN2-0000DJ-Mo for ipsec@optimus.ietf.org; Fri, 21 May 2004 14:03:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18709 for ; Fri, 21 May 2004 14:03:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREN0-0000zN-Ag for ipsec@ietf.org; Fri, 21 May 2004 14:03:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREMC-0000vk-00 for ipsec@ietf.org; Fri, 21 May 2004 14:02:56 -0400 Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx with esmtp (Exim 4.12) id 1BRELh-0000rR-00 for ipsec@ietf.org; Fri, 21 May 2004 14:02:25 -0400 Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i4LI2Ku35134; Fri, 21 May 2004 11:02:20 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Charlie Kaufman" , Date: Fri, 21 May 2004 11:02:31 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] RE: OCSP in IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Charlie, Per very recent discussions with the ADs, I believe we have a more tractable path forward than that I originally proposed. Based on a separate document defining an IANA-allocated extension to the CERT payload content, which extension would define "OCSP Response", this path would enable public discussion of the issues, such as you raise, but would in no way impact forward progress of the IKEv2 I-D. Mike -----Original Message----- From: Charlie Kaufman [mailto:charliek@microsoft.com] Sent: Friday, May 21, 2004 10:38 AM To: ipsec@ietf.org Cc: Michael Myers Subject: RE: OCSP in IKEv2 I agree there will be problems with sizes if people try to pass CRLs as part of the IKE negotiation because CRLs tend to be large and IKE runs over UDP. Adding support to IKEv2 for OCSP is plausible, though I believe it is too late in the process for this big a change in this version. Support for OCSP would likely change the number of messages in the IKEv2 exchange. Longer term I also believe this is a bad idea, but for a different reason. Passing certificates 'in band' in IKE makes sense because they are not reliably accessible by any standardized protocol. Both CRL fetching and OCSP are designed to run over IP (not embedded in another protocol), and so I believe it would be better to use those protocols directly rather than taking them apart and reassembling them inside IPsec. There will be occasions when either the CRL or the OCSP server will only be accessible to an endpoint over an IPsec SA, which introduces a chicken and egg problem. In my opinion, the lesser hack would be allow an IPsec SA to come up with limited connectivity without the CRL or OCSP verification, where the connectivity is limited to that required to fetch the CRL or talk to the OCSP server. I'm sure others would violently disagree with my taste on this matter. But in any case, it seems like a debate better conducted in the PKI4IPSEC working group. --Charlie Kaufman -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Wednesday, May 19, 2004 1:24 PM To: ipsec@ietf.org Subject: OCSP in IKEv2 Charlie, Recent discussions in the PKI4IPSEC working group exposed a disconnect between IKE's specification of CRLs and their utility given likely CRL size. Towards in-band alternatives, OCSP as developed by PKIX and defined by RFC 2560 is a viable option for IKE in-band signaling of certificate revocation status. OCSP did not exist as an RFC when IKE was originally drafted; it was still an I-D at that stage of IKE's development. Its absence in IKE's original specification is thus understandable. But OCSP does now exist as an alternative to CRLs. Per a recent PKIX poll, there are something like eight independent implementations of OCSP. I strongly encourage amendment of IKEv2 to accommodate OCSP. TLS has already done so, as has the OWA community. Why not IPSEC? I realize this notice is probably too late for -13 but might consensus could be formed for inclusion in -14 of IKEv2? Michael Myers _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 21 14:30:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19917 for ; Fri, 21 May 2004 14:30:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRElV-0006BW-VT for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 14:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LIT5mO023775 for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 14:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREgC-00058i-Rk for ipsec-web-archive@optimus.ietf.org; Fri, 21 May 2004 14:23:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19600 for ; Fri, 21 May 2004 14:23:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREgA-0002TZ-76 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 14:23:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREfJ-0002Oq-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 14:22:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BREeK-0002Ki-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 14:21:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREV0-0002V1-J7; Fri, 21 May 2004 14:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREN2-0000DJ-Mo for ipsec@optimus.ietf.org; Fri, 21 May 2004 14:03:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18709 for ; Fri, 21 May 2004 14:03:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREN0-0000zN-Ag for ipsec@ietf.org; Fri, 21 May 2004 14:03:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREMC-0000vk-00 for ipsec@ietf.org; Fri, 21 May 2004 14:02:56 -0400 Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx with esmtp (Exim 4.12) id 1BRELh-0000rR-00 for ipsec@ietf.org; Fri, 21 May 2004 14:02:25 -0400 Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i4LI2Ku35134; Fri, 21 May 2004 11:02:20 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Charlie Kaufman" , Date: Fri, 21 May 2004 11:02:31 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Ipsec] RE: OCSP in IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie, Per very recent discussions with the ADs, I believe we have a more tractable path forward than that I originally proposed. Based on a separate document defining an IANA-allocated extension to the CERT payload content, which extension would define "OCSP Response", this path would enable public discussion of the issues, such as you raise, but would in no way impact forward progress of the IKEv2 I-D. Mike -----Original Message----- From: Charlie Kaufman [mailto:charliek@microsoft.com] Sent: Friday, May 21, 2004 10:38 AM To: ipsec@ietf.org Cc: Michael Myers Subject: RE: OCSP in IKEv2 I agree there will be problems with sizes if people try to pass CRLs as part of the IKE negotiation because CRLs tend to be large and IKE runs over UDP. Adding support to IKEv2 for OCSP is plausible, though I believe it is too late in the process for this big a change in this version. Support for OCSP would likely change the number of messages in the IKEv2 exchange. Longer term I also believe this is a bad idea, but for a different reason. Passing certificates 'in band' in IKE makes sense because they are not reliably accessible by any standardized protocol. Both CRL fetching and OCSP are designed to run over IP (not embedded in another protocol), and so I believe it would be better to use those protocols directly rather than taking them apart and reassembling them inside IPsec. There will be occasions when either the CRL or the OCSP server will only be accessible to an endpoint over an IPsec SA, which introduces a chicken and egg problem. In my opinion, the lesser hack would be allow an IPsec SA to come up with limited connectivity without the CRL or OCSP verification, where the connectivity is limited to that required to fetch the CRL or talk to the OCSP server. I'm sure others would violently disagree with my taste on this matter. But in any case, it seems like a debate better conducted in the PKI4IPSEC working group. --Charlie Kaufman -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Wednesday, May 19, 2004 1:24 PM To: ipsec@ietf.org Subject: OCSP in IKEv2 Charlie, Recent discussions in the PKI4IPSEC working group exposed a disconnect between IKE's specification of CRLs and their utility given likely CRL size. Towards in-band alternatives, OCSP as developed by PKIX and defined by RFC 2560 is a viable option for IKE in-band signaling of certificate revocation status. OCSP did not exist as an RFC when IKE was originally drafted; it was still an I-D at that stage of IKE's development. Its absence in IKE's original specification is thus understandable. But OCSP does now exist as an alternative to CRLs. Per a recent PKIX poll, there are something like eight independent implementations of OCSP. I strongly encourage amendment of IKEv2 to accommodate OCSP. TLS has already done so, as has the OWA community. Why not IPSEC? I realize this notice is probably too late for -13 but might consensus could be formed for inclusion in -14 of IKEv2? Michael Myers _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 21 19:04:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11467 for ; Fri, 21 May 2004 19:04:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRIur-00062L-ST; Fri, 21 May 2004 18:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXdb-0000RP-Jw for ipsec@optimus.ietf.org; Wed, 19 May 2004 16:26:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11908 for ; Wed, 19 May 2004 16:26:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQXdZ-0007Tx-OM for ipsec@ietf.org; Wed, 19 May 2004 16:26:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQXcY-0007Ls-00 for ipsec@ietf.org; Wed, 19 May 2004 16:24:58 -0400 Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx with esmtp (Exim 4.12) id 1BQXbZ-0007Ek-00 for ipsec@ietf.org; Wed, 19 May 2004 16:23:57 -0400 Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i4JKNtu04910 for ; Wed, 19 May 2004 13:23:56 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: Date: Wed, 19 May 2004 13:24:09 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] OCSP in IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Charlie, Recent discussions in the PKI4IPSEC working group exposed a disconnect between IKE's specification of CRLs and their utility given likely CRL size. Towards in-band alternatives, OCSP as developed by PKIX and defined by RFC 2560 is a viable option for IKE in-band signaling of certificate revocation status. OCSP did not exist as an RFC when IKE was originally drafted; it was still an I-D at that stage of IKE's development. Its absence in IKE's original specification is thus understandable. But OCSP does now exist as an alternative to CRLs. Per a recent PKIX poll, there are something like eight independent implementations of OCSP. I strongly encourage amendment of IKEv2 to accommodate OCSP. TLS has already done so, as has the OWA community. Why not IPSEC? I realize this notice is probably too late for -13 but might consensus could be formed for inclusion in -14 of IKEv2? Michael Myers _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 21 19:14:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11909 for ; Fri, 21 May 2004 19:14:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJAB-0001Wg-TY for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 19:10:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LNApar005861 for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 19:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJ5K-0008OP-2G for ipsec-web-archive@optimus.ietf.org; Fri, 21 May 2004 19:05:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11539 for ; Fri, 21 May 2004 19:05:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJ5G-000073-Og for ipsec-web-archive@ietf.org; Fri, 21 May 2004 19:05:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJ4L-00002Z-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 19:04:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRJ3T-0007m0-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 19:03:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRIur-00062L-ST; Fri, 21 May 2004 18:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXdb-0000RP-Jw for ipsec@optimus.ietf.org; Wed, 19 May 2004 16:26:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11908 for ; Wed, 19 May 2004 16:26:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQXdZ-0007Tx-OM for ipsec@ietf.org; Wed, 19 May 2004 16:26:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQXcY-0007Ls-00 for ipsec@ietf.org; Wed, 19 May 2004 16:24:58 -0400 Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx with esmtp (Exim 4.12) id 1BQXbZ-0007Ek-00 for ipsec@ietf.org; Wed, 19 May 2004 16:23:57 -0400 Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i4JKNtu04910 for ; Wed, 19 May 2004 13:23:56 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: Date: Wed, 19 May 2004 13:24:09 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Ipsec] OCSP in IKEv2 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie, Recent discussions in the PKI4IPSEC working group exposed a disconnect between IKE's specification of CRLs and their utility given likely CRL size. Towards in-band alternatives, OCSP as developed by PKIX and defined by RFC 2560 is a viable option for IKE in-band signaling of certificate revocation status. OCSP did not exist as an RFC when IKE was originally drafted; it was still an I-D at that stage of IKE's development. Its absence in IKE's original specification is thus understandable. But OCSP does now exist as an alternative to CRLs. Per a recent PKIX poll, there are something like eight independent implementations of OCSP. I strongly encourage amendment of IKEv2 to accommodate OCSP. TLS has already done so, as has the OWA community. Why not IPSEC? I realize this notice is probably too late for -13 but might consensus could be formed for inclusion in -14 of IKEv2? Michael Myers _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 21 19:33:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12646 for ; Fri, 21 May 2004 19:33:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJRm-0004c3-V4; Fri, 21 May 2004 19:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJLk-0003nN-V3 for ipsec@optimus.ietf.org; Fri, 21 May 2004 19:22:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12282 for ; Fri, 21 May 2004 19:22:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJLj-0001jh-Ac for ipsec@ietf.org; Fri, 21 May 2004 19:22:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJL1-0001eX-00 for ipsec@ietf.org; Fri, 21 May 2004 19:22:03 -0400 Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx with esmtp (Exim 4.12) id 1BRJK4-0001Rs-00 for ipsec@ietf.org; Fri, 21 May 2004 19:21:04 -0400 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 65AE871E3; Fri, 21 May 2004 16:22:50 -0700 (PDT) To: "Michael Myers" Cc: ipsec@ietf.org Subject: Re: [Ipsec] OCSP in IKEv2 In-reply-to: Your message of "Wed, 19 May 2004 13:24:09 PDT." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 14) Date: Fri, 21 May 2004 16:20:27 -0700 From: Eric Rescorla Message-Id: <20040521232250.65AE871E3@sierra.rtfm.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Michael Myers wrote: > I strongly encourage amendment of IKEv2 to accommodate OCSP. > TLS has already done so, as has the OWA community. Why not > IPSEC? I realize this notice is probably too late for -13 but > might consensus could be formed for inclusion in -14 of IKEv2? Mike, I don't mean to be difficult, but in what way do you believe that TLS has accomodated OCSP, except to the extent to which it's failed to accomodate CRLs? -Ekr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 21 19:40:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12914 for ; Fri, 21 May 2004 19:40:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJaA-0006w0-CT for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 19:37:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LNbgfF026652 for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 19:37:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJXN-00067v-Ll for ipsec-web-archive@optimus.ietf.org; Fri, 21 May 2004 19:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12708 for ; Fri, 21 May 2004 19:34:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJXL-0002nG-RS for ipsec-web-archive@ietf.org; Fri, 21 May 2004 19:34:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJWR-0002fX-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 19:33:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRJVV-0002Z5-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 19:32:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJRm-0004c3-V4; Fri, 21 May 2004 19:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJLk-0003nN-V3 for ipsec@optimus.ietf.org; Fri, 21 May 2004 19:22:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12282 for ; Fri, 21 May 2004 19:22:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJLj-0001jh-Ac for ipsec@ietf.org; Fri, 21 May 2004 19:22:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJL1-0001eX-00 for ipsec@ietf.org; Fri, 21 May 2004 19:22:03 -0400 Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx with esmtp (Exim 4.12) id 1BRJK4-0001Rs-00 for ipsec@ietf.org; Fri, 21 May 2004 19:21:04 -0400 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 65AE871E3; Fri, 21 May 2004 16:22:50 -0700 (PDT) To: "Michael Myers" Cc: ipsec@ietf.org Subject: Re: [Ipsec] OCSP in IKEv2 In-reply-to: Your message of "Wed, 19 May 2004 13:24:09 PDT." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 14) Date: Fri, 21 May 2004 16:20:27 -0700 From: Eric Rescorla Message-Id: <20040521232250.65AE871E3@sierra.rtfm.com> Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Michael Myers wrote: > I strongly encourage amendment of IKEv2 to accommodate OCSP. > TLS has already done so, as has the OWA community. Why not > IPSEC? I realize this notice is probably too late for -13 but > might consensus could be formed for inclusion in -14 of IKEv2? Mike, I don't mean to be difficult, but in what way do you believe that TLS has accomodated OCSP, except to the extent to which it's failed to accomodate CRLs? -Ekr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 21 20:02:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14222 for ; Fri, 21 May 2004 20:02:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJsr-0001Mf-NM; Fri, 21 May 2004 19:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJkt-0000Mf-7B for ipsec@optimus.ietf.org; Fri, 21 May 2004 19:48:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13347 for ; Fri, 21 May 2004 19:48:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJkr-00044w-DF for ipsec@ietf.org; Fri, 21 May 2004 19:48:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJjv-0003zy-00 for ipsec@ietf.org; Fri, 21 May 2004 19:47:47 -0400 Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx with esmtp (Exim 4.12) id 1BRJix-0003vF-00 for ipsec@ietf.org; Fri, 21 May 2004 19:46:48 -0400 Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i4LNkku68728; Fri, 21 May 2004 16:46:46 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Eric Rescorla" Cc: Subject: RE: [Ipsec] OCSP in IKEv2 Date: Fri, 21 May 2004 16:46:56 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20040521232250.65AE871E3@sierra.rtfm.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eric, See Section 3.6 of RFC 3546. http://www.ietf.org/rfc/rfc3546.txt Mike -----Original Message----- From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org]On Behalf Of Eric Rescorla Mike, I don't mean to be difficult, but in what way do you believe that TLS has accomodated OCSP, except to the extent to which it's failed to accomodate CRLs? -Ekr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Fri May 21 20:17:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14916 for ; Fri, 21 May 2004 20:17:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRKAP-0005r7-8P for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 20:15:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M0F9f8022503 for ipsec-archive@odin.ietf.org; Fri, 21 May 2004 20:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJzT-0003LC-Gh for ipsec-web-archive@optimus.ietf.org; Fri, 21 May 2004 20:03:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14303 for ; Fri, 21 May 2004 20:03:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJzR-0005eD-9p for ipsec-web-archive@ietf.org; Fri, 21 May 2004 20:03:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJyU-0005Xv-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 20:02:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRJxY-0005Ra-00 for ipsec-web-archive@ietf.org; Fri, 21 May 2004 20:01:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJsr-0001Mf-NM; Fri, 21 May 2004 19:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJkt-0000Mf-7B for ipsec@optimus.ietf.org; Fri, 21 May 2004 19:48:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13347 for ; Fri, 21 May 2004 19:48:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJkr-00044w-DF for ipsec@ietf.org; Fri, 21 May 2004 19:48:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJjv-0003zy-00 for ipsec@ietf.org; Fri, 21 May 2004 19:47:47 -0400 Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx with esmtp (Exim 4.12) id 1BRJix-0003vF-00 for ipsec@ietf.org; Fri, 21 May 2004 19:46:48 -0400 Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i4LNkku68728; Fri, 21 May 2004 16:46:46 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "Eric Rescorla" Cc: Subject: RE: [Ipsec] OCSP in IKEv2 Date: Fri, 21 May 2004 16:46:56 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20040521232250.65AE871E3@sierra.rtfm.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, See Section 3.6 of RFC 3546. http://www.ietf.org/rfc/rfc3546.txt Mike -----Original Message----- From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org]On Behalf Of Eric Rescorla Mike, I don't mean to be difficult, but in what way do you believe that TLS has accomodated OCSP, except to the extent to which it's failed to accomodate CRLs? -Ekr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat May 22 05:12:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21927 for ; Sat, 22 May 2004 05:12:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSOO-0007Uj-B7; Sat, 22 May 2004 05:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSJY-0006Jj-Ak for ipsec@optimus.ietf.org; Sat, 22 May 2004 04:57:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21373 for ; Sat, 22 May 2004 04:57:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRSJV-0007ET-4v for ipsec@ietf.org; Sat, 22 May 2004 04:57:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRSIZ-00077B-00 for ipsec@ietf.org; Sat, 22 May 2004 04:56:07 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BRSHg-0006zw-00 for ipsec@ietf.org; Sat, 22 May 2004 04:55:12 -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 i4M8rio20878 for ; Sat, 22 May 2004 04:53:45 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4M8qerB010409 for ; Sat, 22 May 2004 04:52:40 -0400 (EDT) Received: from node-d-4c3a.a2000.nl(62.195.76.58) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjCaWtu; Sat, 22 May 04 04:52:34 -0400 Date: Sat, 22 May 2004 09:55:14 +0000 To: "Ipsec" From: "Fukuda" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------eqtvojiiivuicwclsfmb" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Incoming Msg Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------eqtvojiiivuicwclsfmb Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------eqtvojiiivuicwclsfmb Content-Type: text/html; name="You_will_answer_to_me.com.htm" Content-Disposition: attachment; filename="You_will_answer_to_me.com.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: You_will_answer_to_me.com
Virus name: W32/Bagle.aa@MM

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

----------eqtvojiiivuicwclsfmb-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sat May 22 05:35:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22598 for ; Sat, 22 May 2004 05:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSrv-0004Qt-7S for ipsec-archive@odin.ietf.org; Sat, 22 May 2004 05:32:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M9Wdkq017040 for ipsec-archive@odin.ietf.org; Sat, 22 May 2004 05:32:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSmq-0003MR-QC for ipsec-web-archive@optimus.ietf.org; Sat, 22 May 2004 05:27:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22388 for ; Sat, 22 May 2004 05:27:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRSmn-0003jM-9w for ipsec-web-archive@ietf.org; Sat, 22 May 2004 05:27:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRSli-0003Pj-00 for ipsec-web-archive@ietf.org; Sat, 22 May 2004 05:26:14 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRSjp-000377-01 for ipsec-web-archive@ietf.org; Sat, 22 May 2004 05:24:17 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRSYQ-0004g4-B5 for ipsec-web-archive@ietf.org; Sat, 22 May 2004 05:12:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSOO-0007Uj-B7; Sat, 22 May 2004 05:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSJY-0006Jj-Ak for ipsec@optimus.ietf.org; Sat, 22 May 2004 04:57:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21373 for ; Sat, 22 May 2004 04:57:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRSJV-0007ET-4v for ipsec@ietf.org; Sat, 22 May 2004 04:57:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRSIZ-00077B-00 for ipsec@ietf.org; Sat, 22 May 2004 04:56:07 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BRSHg-0006zw-00 for ipsec@ietf.org; Sat, 22 May 2004 04:55:12 -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 i4M8rio20878 for ; Sat, 22 May 2004 04:53:45 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4M8qerB010409 for ; Sat, 22 May 2004 04:52:40 -0400 (EDT) Received: from node-d-4c3a.a2000.nl(62.195.76.58) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjCaWtu; Sat, 22 May 04 04:52:34 -0400 Date: Sat, 22 May 2004 09:55:14 +0000 To: "Ipsec" From: "Fukuda" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------eqtvojiiivuicwclsfmb" Subject: [Ipsec] RE: Incoming Msg Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------eqtvojiiivuicwclsfmb Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------eqtvojiiivuicwclsfmb Content-Type: text/html; name="You_will_answer_to_me.com.htm" Content-Disposition: attachment; filename="You_will_answer_to_me.com.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: You_will_answer_to_me.com
Virus name: W32/Bagle.aa@MM

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

----------eqtvojiiivuicwclsfmb-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat May 22 07:00:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28302 for ; Sat, 22 May 2004 07:00:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRU2w-0000NQ-TV; Sat, 22 May 2004 06:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRTuO-0007Fs-Qc for ipsec@optimus.ietf.org; Sat, 22 May 2004 06:39:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27161 for ; Sat, 22 May 2004 06:39:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRTuK-0007jQ-H0 for ipsec@ietf.org; Sat, 22 May 2004 06:39:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRTtP-0007aa-00 for ipsec@ietf.org; Sat, 22 May 2004 06:38:15 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BRTsm-0007Qn-00 for ipsec@ietf.org; Sat, 22 May 2004 06:37:36 -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 i4MAa9o00652 for ; Sat, 22 May 2004 06:36:09 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4MAZ69D022174 for ; Sat, 22 May 2004 06:35:06 -0400 (EDT) Received: from unknown(203.199.214.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAASVaatR; Sat, 22 May 04 06:35:04 -0400 Date: Sat, 22 May 2004 15:57:58 +0530 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ahbhohdcksipvdqhtmyt" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Protected message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------ahbhohdcksipvdqhtmyt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ahbhohdcksipvdqhtmyt Content-Type: application/octet-stream; name="Details.vbs" Content-Disposition: attachment; filename="Details.vbs" Content-Transfer-Encoding: base64 ----------ahbhohdcksipvdqhtmyt-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Sat May 22 07:21:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29779 for ; Sat, 22 May 2004 07:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUQV-0004mY-Rz for ipsec-archive@odin.ietf.org; Sat, 22 May 2004 07:12:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MBCRHf018376 for ipsec-archive@odin.ietf.org; Sat, 22 May 2004 07:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUGf-0002Rj-7v for ipsec-web-archive@optimus.ietf.org; Sat, 22 May 2004 07:02:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28467 for ; Sat, 22 May 2004 07:02:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRUGa-0003gR-Tw for ipsec-web-archive@ietf.org; Sat, 22 May 2004 07:02:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUFd-0003Qq-00 for ipsec-web-archive@ietf.org; Sat, 22 May 2004 07:01:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRUEd-0003Cb-00 for ipsec-web-archive@ietf.org; Sat, 22 May 2004 07:00:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRU2w-0000NQ-TV; Sat, 22 May 2004 06:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRTuO-0007Fs-Qc for ipsec@optimus.ietf.org; Sat, 22 May 2004 06:39:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27161 for ; Sat, 22 May 2004 06:39:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRTuK-0007jQ-H0 for ipsec@ietf.org; Sat, 22 May 2004 06:39:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRTtP-0007aa-00 for ipsec@ietf.org; Sat, 22 May 2004 06:38:15 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BRTsm-0007Qn-00 for ipsec@ietf.org; Sat, 22 May 2004 06:37:36 -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 i4MAa9o00652 for ; Sat, 22 May 2004 06:36:09 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4MAZ69D022174 for ; Sat, 22 May 2004 06:35:06 -0400 (EDT) Received: from unknown(203.199.214.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAASVaatR; Sat, 22 May 04 06:35:04 -0400 Date: Sat, 22 May 2004 15:57:58 +0530 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ahbhohdcksipvdqhtmyt" Subject: [Ipsec] Protected message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.60 ----------ahbhohdcksipvdqhtmyt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ahbhohdcksipvdqhtmyt Content-Type: application/octet-stream; name="Details.vbs" Content-Disposition: attachment; filename="Details.vbs" Content-Transfer-Encoding: base64 ----------ahbhohdcksipvdqhtmyt-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun May 23 21:18:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18311 for ; Sun, 23 May 2004 21:18:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS3xe-0005BK-I0; Sun, 23 May 2004 21:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS3rs-00048c-7Q for ipsec@optimus.ietf.org; Sun, 23 May 2004 21:03:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17644 for ; Sun, 23 May 2004 21:03:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS3rp-0006qj-Oe for ipsec@ietf.org; Sun, 23 May 2004 21:03:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS3qp-0006a5-00 for ipsec@ietf.org; Sun, 23 May 2004 21:02:01 -0400 Received: from rs9.luxsci.com ([66.216.98.59]) by ietf-mx with esmtp (Exim 4.12) id 1BS3pp-00063c-00 for ipsec@ietf.org; Sun, 23 May 2004 21:00:57 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i4O10RSA026532 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 23 May 2004 20:00:27 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i4O0w1rb026245; Mon, 24 May 2004 00:58:01 GMT Message-Id: <200405240058.i4O0w1rb026245@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Mon, 24 May 2004 00:58:01 +0000 From: "William Dixon" To: "'Charlie Kaufman'" , Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 Date: Sun, 23 May 2004 20:57:16 -0400 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 - 1085360281-3488529.29556124 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Charlie, I note that the current comments on the discoverability of information through passive monitoring and through active probing is not complete. I'd prefer that we err on the side of explicitly explaining the risks of the protocol design where certain types of use of protocol features would be risky. Regarding: "To avoid probing, the initiator of an exchange is required to identify itself first, and usually is required to authenticate itself first. The initiator can, however, learn that the responder supports IKE and what cryptographic protocols it supports." Comments: Deployment situations require a responder to advertise aspects of itself or to keep aspects of itself private. I made a comment at an IETF 2 or 3 years ago that I wish that the protocol accommodated the ability for a responder to authenticate first when operating in "public mode", but that is water under the IKEv2 bridge I guess. I also spoke in support of a requirements document could have specified what scenarios IKEv2 was suited for. Certainly none now that require a server to authenticate before a client... To the text quoted above, the optional CERTREQ from the responder reveals the trust anchors that the unauthenticated responder would presumably use to authenticate the initiator. Certain usages of the CERTREQ payload (by default for example) in products may inadvertently increase the risk to the customer. The risk is when the CERTREQ contains a DN of a CA name that identifies the organizational owner of the gateway, and certainly which trust infrastructure must be compromised. This could provide important information to the attacker if the CA name were the lowest level of issuing authority for which a certificate was accepted (such as "Defense Nuclear Analysis Branch Issuing CA"), or perhaps generally useful but less specific information if the CA DN name were the root CA name (such as "Defense Dept Root CA"). The use of PKI technology and certain privately owned PKIs for IKEv2 may not in fact be something that is intended to be known or advertised publicly. Thus it may be necessary to rely solely upon initiator configuration or user selection to know which certificate to offer. To avoid the IKEv2 draft becoming a dissertation on how to probe and attack IKE, I think a new draft detailing this should be submitted. In fact, I think such a draft should be required of a security protocol so that developers have a very clear understanding of how their product implementation can be attacked or used for surveillance or to gather pre-attack information. Clearly those building such tools will know it. So my change text for -14 is: "The initiator of an IKEv2 negotiation can discover information about a responder. While IKEv2 is designed such that the initiator can not discover the full identity of the responder, the support of certain features of the protocol in implementations as well as their particular use in deployment may provide useful information for adversaries.[IKEv2ATTACK]" [IKEv2ATTACK] TBD. If the WG would like to advance such a draft, I can offer an initial one in approximately mid to late July. Wm > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Charlie Kaufman > Sent: Sunday, May 16, 2004 1:50 AM > To: ipsec@ietf.org > Subject: [Ipsec] Proposed Last Call based revisions to IKEv2 > > Based on the discussion on the list, I believe these are the > final edits to IKEv2. If anyone disagrees, please speak up > before I send out -14. > > --Charlie > > (Diffs to source with typos and version # changes omitted): > Issue #99 > ============================================================== > ========== > === > ***************************************************** > i040322.txt, Line > 349 > ! ! IPsec ! ! > !Protected! Tunnel !Protected! > ***************************************************** > i040509.txt, Line > 349 > ! ! IPsec Transport ! ! > !Protected! or Tunnel Mode SA !Protected! > ============================================================== > ========== > === > ***************************************************** > i040322.txt, Line > 359 > IPsec. These endpoints may implement application layer access > controls based on the authenticated identities of the > participants. Transport mode will commonly be used with no > inner IP header. If there is an inner IP header, the inner > addresses will be the same as the outer addresses. A single > pair of addresses will be negotiated for packets to be > protected by this SA. > ***************************************************** > i040509.txt, Line > 359 > IPsec, as required of hosts in [RFC2401bis]. Transport mode > will commonly be used with no inner IP header. > If there is an inner IP header, the inner addresses will be > the same as the outer addresses. A single pair of addresses > will be negotiated for packets to be protected by this SA. > These endpoints MAY implement application layer access > controls based on the IPsec authenticated identities of the > participants. This scenario enables the end-to-end security > that has been a guiding principle for the Internet since > [RFC1958], [RFC2775], and a method of limiting the inherent > problems with complexity in networks noted by [RFC3439]. > While this scenario may not be fully applicable to the IPv4 > Internet, it has been deployed successfully in specific > scenarios within intranets using IKEv1. It should be more > broadly enabled during the transition to IPv6 and with the > adoption of IKEv2. > > > > Completion of change to AUTH calculation recommended by Hugo > and CFRG > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 1581 > SK_pi and SK_pr which are only used when authenticating with > an EAP authentication mechanism that does not generate a shared key. > **************************************************** i040509.txt, Line > 1589 > SK_pi and SK_pr which are used when generating an AUTH payload. > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 1628 > prf(SK_ar,IDr') where IDr' is the responder's ID payload > excluding the fixed header. Note that neither the nonce Ni > nor the value > prf(SK_ar,IDr') > are transmitted. Similarly, the initiator signs the first > message, starting with the first octet of the first SPI in > the header and ending with the last octet of the last payload. > Appended to this (for purposes of computing the signature) > are the responder's nonce Nr, and the value prf(SK_ai,IDi'). > In the above calculation, > **************************************************** i040509.txt, Line > 1636 > prf(SK_pr,IDr') where IDr' is the responder's ID payload > excluding the fixed header. Note that neither the nonce Ni > nor the value > prf(SK_pr,IDr') > are transmitted. Similarly, the initiator signs the first > message, starting with the first octet of the first SPI in > the header and ending with the last octet of the last payload. > Appended to this (for purposes of computing the signature) > are the responder's nonce Nr, and the value prf(SK_pi,IDi'). > In the above calculation, > > > > Wording error reported by Mohan Parthasarathy > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 2117 > some older NATs modify IKE traffic on port 500 in an attempt > to transparently establish IPsec connections. Such NATs may > interfere with the > **************************************************** i040509.txt, Line > 2125 > some older NATs handle IKE traffic on port 500 cleverly in an > attempt to transparently establish IPsec connections between > endpoints that don't handle NAT traversal themselves. Such > NATs may interfere with the > > > > > Issue #103 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 2808 > AUTH_AES_XCBC_96 5 > **************************************************** i040509.txt, Line > 2818 > AUTH_AES_PRF_128 5 (RFC3664) > > > > > Proposal from Ted Ts'o 4/6/04 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 3199 > An opaque octet stream which may be used to pass an account name or > **************************************************** i040509.txt, Line > 3209 > An opaque octet stream which may be used > > > > > Issue #94 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 3328 > id-mod-cert-bundle(TBD) } > **************************************************** i040509.txt, Line > 3337 > id-mod-cert-bundle(34) } > > > > > > Issue #96, 98 > ============================================================== > ========== > === > **************************************************** > i040322.txt, Line 3930 > RESERVED TO IANA - STATUS TYPES 16395 - 40959 > **************************************************** > i040509.txt, Line 3960 > NON_FIRST_FRAGMENTS_ALSO 16395 > .sp > .in 12 > This notification occurs may occur in the request and > response of a CREATE_CHILD_SA exchange. It indicates that its > sender would like to send and is willing to receive > non-initial IP fragments on the SA being established if the > corresponding initial IP fragment was sent on the SA even if > the SA does not negotiation the sending of OPAQUE packets. > This notification MUST NOT be send in a response unless it > was present in the corresponding request and both ends MUST > NOT send such fragments unless this notification was present > in both the request and the response. > .in 8 > RESERVED TO IANA - STATUS TYPES 16396 - 40959 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 4144 > which port is undefined, or if all ports are allowed or > port is OPAQUE, this field MUST be zero. For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer (with Type in the most > significant eight bits and Code in the least significant > eight bits) port number for the purposes of filtering based > on this field. > .sp > o End Port (2 octets) - Value specifying the largest port > number allowed by this Traffic Selector. For protocols for > which port is undefined, or if all ports are allowed or > port is OPAQUE, this field MUST be 65535. For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer (with Type in the most > significant eight bits and Code in the least significant > eight bits) port number for the purposed of filtering based > on this field. > **************************************************** i040509.txt, Line > 4186 > which port is undefined, or if all ports and packets where > port is OPAQUE are allowed, this field MUST be zero. For > the ICMP protocol, the two one octet fields Type and Code > are treated as a single 16 bit integer (with Type in the > most significant eight bits and Code in the least > significant eight bits) port number for the purposes of > filtering based on this field. A Start Port value of 65535 > with an End Port value of 0 in a traffic selector indicates > non-initial IP fragments where the port is therefore OPAQUE. > Any other Traffic Selector where Start Port > End Port is > invalid, MUST NOT be sent, and MUST be ignored on receipt. > .sp > o End Port (2 octets) - Value specifying the largest port > number allowed by this Traffic Selector. For protocols for > which port is undefined, or if all ports and packets where > port is OPAQUE are allowed, this field MUST be 65535. For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer (with Type in the most > significant eight bits and Code in the least significant > eight bits) port number for the purposed of filtering based > on this field. A Start Port value of 65535 with an End Port > value of 0 in a traffic selector indicates non-initial IP > fragments where the port is therefore OPAQUE. Any other > Traffic Selector where Start Port > End Port is invalid, > MUST NOT be sent, and MUST be ignored on receipt. > > > > Issue #97 > ============================================================== > ========== > === > **************************************************** > i040322.txt, Line 4740 sufficient for use with 3DES. Groups > three through five provide greater security. Group one is for > historic purposes only and does not provide sufficient > strength except for use with DES, which is also for historic > use only. Implementations should make note of these > conservative estimates when establishing > **************************************************** i040509.txt, Line > 4806 > common for use with 3DES. Group five provides greater > security than group two. > Group one is for historic purposes only and does not provide > sufficient strength except for use with DES, which is also > for historic use only. Implementations should make note of > these estimates when establishing > > > > > Issue #100 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 3426 > a chain of certificates. If a certificate exists which > satisfies the criteria specified in the Certificate Request > Payload, the certificate MUST be sent back to the certificate > requestor; if a certificate chain exists which goes back to > the certification authority specified in the request the > entire chain SHOULD be sent back to the certificate > requestor. If multiple certificates or chains exist that > satisfy the request, the sender MUST pick one. If no > certificates exist then the Certificate Request Payload is ignored. > This > is not an error condition of the protocol. There may be cases > where there is a preferred CA, but an alternate might be > acceptable (perhaps after prompting a human operator). > **************************************************** i040509.txt, Line > 3435 > a chain of certificates. > > If an end-entity certificate exists which satisfies the > criteria specified in the CERTREQ, a certificate or > certificate chain SHOULD be sent back to the certificate requestor if: > .sp > - the recipient of the CERTREQ is configured to use > certificate authentication, .sp > - is allowed to send a CERT payload, > .sp > - has matching CA trust policy governing the current > negotiation, and .sp > - has at least one time-wise and usage appropriate > end-entity certificate chaining to a CA provided in the CERTREQ. > .sp > Certificate revocation checking must be considered during the > chaining process used to select a certificate. Note that even > if two peers are configured to use two different CAs, > cross-certification relationships should be supported by > appropriate selection logic. The intent is not to prevent > communication through the strict adherence of selection of a > certificate based on CERTREQ, when an alternate certificate > could be selected by the sender which would still enable the > recipient to successfully validate and trust it through trust > conveyed by cross-certification, CRLs or other out-of-band > configured 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 condition of the protocol. > There may be cases where there is a preferred CA sent in the > CERTREQ, but an alternate might be acceptable (perhaps after > prompting a human operator)." > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 4727 > **************************************************** i040509.txt, Line > 4777 > While this protocol is designed to minimize disclosure of > configuration information to unauthenticated peers, some such > disclosure is unavoidable. > One peer or the other must identify itself first and prove > its identity first. > To avoid probing, the initiator of an exchange is required to > identify itself first, and usually is required to > authenticate itself first. The initiator can, however, learn > that the responder supports IKE and what cryptographic > protocols it supports. The responder (or someone > impersonating the responder) can probe the initiator not only > for its identity, but using CERTREQ payloads may be able to > determine what certificates the initiator is willing to use. > .sp > Use of EAP authentication changes the probing possibilities somewhat. > When > EAP authentication is used, the responder proves its identity > before the initiator does, so an initiator that knew the name > of a valid initiator could probe the responder for both its > name and certificates. > .sp > ============================================================== > ========== > === > **************************************************** > i040322.txt, Line 5010 > **************************************************** i040509.txt, Line > 5077 > > [RFC1958] Carpenter, B., "Architectural Principles of the > Internet", RFC 1958, June 1996. > ============================================================== > ========== > === > **************************************************** > i040322.txt, Line 5030 > [RFC2983] Black, D., "Differentiated Services and Tunnels", > RFC 2983, October 2000. > **************************************************** > i040509.txt, Line 5100 > [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, > February 2000. > > [RFC2983] Black, D., "Differentiated Services and Tunnels", > RFC 2983, October 2000. > > [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural > Guidelines and Philosophy", RFC 3429, December 2002. > > _______________________________________________ > 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 exim@www1.ietf.org Sun May 23 21:23:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18516 for ; Sun, 23 May 2004 21:23:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS48g-000739-9W for ipsec-archive@odin.ietf.org; Sun, 23 May 2004 21:20:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O1KQ3I027099 for ipsec-archive@odin.ietf.org; Sun, 23 May 2004 21:20:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS48H-0006uI-BK for ipsec-web-archive@optimus.ietf.org; Sun, 23 May 2004 21:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18373 for ; Sun, 23 May 2004 21:19:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS48E-0003hb-Ha for ipsec-web-archive@ietf.org; Sun, 23 May 2004 21:19:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS47D-0003Qs-00 for ipsec-web-archive@ietf.org; Sun, 23 May 2004 21:18:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS46P-0003AV-00 for ipsec-web-archive@ietf.org; Sun, 23 May 2004 21:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS3xe-0005BK-I0; Sun, 23 May 2004 21:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS3rs-00048c-7Q for ipsec@optimus.ietf.org; Sun, 23 May 2004 21:03:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17644 for ; Sun, 23 May 2004 21:03:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS3rp-0006qj-Oe for ipsec@ietf.org; Sun, 23 May 2004 21:03:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS3qp-0006a5-00 for ipsec@ietf.org; Sun, 23 May 2004 21:02:01 -0400 Received: from rs9.luxsci.com ([66.216.98.59]) by ietf-mx with esmtp (Exim 4.12) id 1BS3pp-00063c-00 for ipsec@ietf.org; Sun, 23 May 2004 21:00:57 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i4O10RSA026532 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 23 May 2004 20:00:27 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i4O0w1rb026245; Mon, 24 May 2004 00:58:01 GMT Message-Id: <200405240058.i4O0w1rb026245@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Mon, 24 May 2004 00:58:01 +0000 From: "William Dixon" To: "'Charlie Kaufman'" , Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 Date: Sun, 23 May 2004 20:57:16 -0400 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 - 1085360281-3488529.29556124 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie, I note that the current comments on the discoverability of information through passive monitoring and through active probing is not complete. I'd prefer that we err on the side of explicitly explaining the risks of the protocol design where certain types of use of protocol features would be risky. Regarding: "To avoid probing, the initiator of an exchange is required to identify itself first, and usually is required to authenticate itself first. The initiator can, however, learn that the responder supports IKE and what cryptographic protocols it supports." Comments: Deployment situations require a responder to advertise aspects of itself or to keep aspects of itself private. I made a comment at an IETF 2 or 3 years ago that I wish that the protocol accommodated the ability for a responder to authenticate first when operating in "public mode", but that is water under the IKEv2 bridge I guess. I also spoke in support of a requirements document could have specified what scenarios IKEv2 was suited for. Certainly none now that require a server to authenticate before a client... To the text quoted above, the optional CERTREQ from the responder reveals the trust anchors that the unauthenticated responder would presumably use to authenticate the initiator. Certain usages of the CERTREQ payload (by default for example) in products may inadvertently increase the risk to the customer. The risk is when the CERTREQ contains a DN of a CA name that identifies the organizational owner of the gateway, and certainly which trust infrastructure must be compromised. This could provide important information to the attacker if the CA name were the lowest level of issuing authority for which a certificate was accepted (such as "Defense Nuclear Analysis Branch Issuing CA"), or perhaps generally useful but less specific information if the CA DN name were the root CA name (such as "Defense Dept Root CA"). The use of PKI technology and certain privately owned PKIs for IKEv2 may not in fact be something that is intended to be known or advertised publicly. Thus it may be necessary to rely solely upon initiator configuration or user selection to know which certificate to offer. To avoid the IKEv2 draft becoming a dissertation on how to probe and attack IKE, I think a new draft detailing this should be submitted. In fact, I think such a draft should be required of a security protocol so that developers have a very clear understanding of how their product implementation can be attacked or used for surveillance or to gather pre-attack information. Clearly those building such tools will know it. So my change text for -14 is: "The initiator of an IKEv2 negotiation can discover information about a responder. While IKEv2 is designed such that the initiator can not discover the full identity of the responder, the support of certain features of the protocol in implementations as well as their particular use in deployment may provide useful information for adversaries.[IKEv2ATTACK]" [IKEv2ATTACK] TBD. If the WG would like to advance such a draft, I can offer an initial one in approximately mid to late July. Wm > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Charlie Kaufman > Sent: Sunday, May 16, 2004 1:50 AM > To: ipsec@ietf.org > Subject: [Ipsec] Proposed Last Call based revisions to IKEv2 > > Based on the discussion on the list, I believe these are the > final edits to IKEv2. If anyone disagrees, please speak up > before I send out -14. > > --Charlie > > (Diffs to source with typos and version # changes omitted): > Issue #99 > ============================================================== > ========== > === > ***************************************************** > i040322.txt, Line > 349 > ! ! IPsec ! ! > !Protected! Tunnel !Protected! > ***************************************************** > i040509.txt, Line > 349 > ! ! IPsec Transport ! ! > !Protected! or Tunnel Mode SA !Protected! > ============================================================== > ========== > === > ***************************************************** > i040322.txt, Line > 359 > IPsec. These endpoints may implement application layer access > controls based on the authenticated identities of the > participants. Transport mode will commonly be used with no > inner IP header. If there is an inner IP header, the inner > addresses will be the same as the outer addresses. A single > pair of addresses will be negotiated for packets to be > protected by this SA. > ***************************************************** > i040509.txt, Line > 359 > IPsec, as required of hosts in [RFC2401bis]. Transport mode > will commonly be used with no inner IP header. > If there is an inner IP header, the inner addresses will be > the same as the outer addresses. A single pair of addresses > will be negotiated for packets to be protected by this SA. > These endpoints MAY implement application layer access > controls based on the IPsec authenticated identities of the > participants. This scenario enables the end-to-end security > that has been a guiding principle for the Internet since > [RFC1958], [RFC2775], and a method of limiting the inherent > problems with complexity in networks noted by [RFC3439]. > While this scenario may not be fully applicable to the IPv4 > Internet, it has been deployed successfully in specific > scenarios within intranets using IKEv1. It should be more > broadly enabled during the transition to IPv6 and with the > adoption of IKEv2. > > > > Completion of change to AUTH calculation recommended by Hugo > and CFRG > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 1581 > SK_pi and SK_pr which are only used when authenticating with > an EAP authentication mechanism that does not generate a shared key. > **************************************************** i040509.txt, Line > 1589 > SK_pi and SK_pr which are used when generating an AUTH payload. > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 1628 > prf(SK_ar,IDr') where IDr' is the responder's ID payload > excluding the fixed header. Note that neither the nonce Ni > nor the value > prf(SK_ar,IDr') > are transmitted. Similarly, the initiator signs the first > message, starting with the first octet of the first SPI in > the header and ending with the last octet of the last payload. > Appended to this (for purposes of computing the signature) > are the responder's nonce Nr, and the value prf(SK_ai,IDi'). > In the above calculation, > **************************************************** i040509.txt, Line > 1636 > prf(SK_pr,IDr') where IDr' is the responder's ID payload > excluding the fixed header. Note that neither the nonce Ni > nor the value > prf(SK_pr,IDr') > are transmitted. Similarly, the initiator signs the first > message, starting with the first octet of the first SPI in > the header and ending with the last octet of the last payload. > Appended to this (for purposes of computing the signature) > are the responder's nonce Nr, and the value prf(SK_pi,IDi'). > In the above calculation, > > > > Wording error reported by Mohan Parthasarathy > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 2117 > some older NATs modify IKE traffic on port 500 in an attempt > to transparently establish IPsec connections. Such NATs may > interfere with the > **************************************************** i040509.txt, Line > 2125 > some older NATs handle IKE traffic on port 500 cleverly in an > attempt to transparently establish IPsec connections between > endpoints that don't handle NAT traversal themselves. Such > NATs may interfere with the > > > > > Issue #103 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 2808 > AUTH_AES_XCBC_96 5 > **************************************************** i040509.txt, Line > 2818 > AUTH_AES_PRF_128 5 (RFC3664) > > > > > Proposal from Ted Ts'o 4/6/04 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 3199 > An opaque octet stream which may be used to pass an account name or > **************************************************** i040509.txt, Line > 3209 > An opaque octet stream which may be used > > > > > Issue #94 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 3328 > id-mod-cert-bundle(TBD) } > **************************************************** i040509.txt, Line > 3337 > id-mod-cert-bundle(34) } > > > > > > Issue #96, 98 > ============================================================== > ========== > === > **************************************************** > i040322.txt, Line 3930 > RESERVED TO IANA - STATUS TYPES 16395 - 40959 > **************************************************** > i040509.txt, Line 3960 > NON_FIRST_FRAGMENTS_ALSO 16395 > .sp > .in 12 > This notification occurs may occur in the request and > response of a CREATE_CHILD_SA exchange. It indicates that its > sender would like to send and is willing to receive > non-initial IP fragments on the SA being established if the > corresponding initial IP fragment was sent on the SA even if > the SA does not negotiation the sending of OPAQUE packets. > This notification MUST NOT be send in a response unless it > was present in the corresponding request and both ends MUST > NOT send such fragments unless this notification was present > in both the request and the response. > .in 8 > RESERVED TO IANA - STATUS TYPES 16396 - 40959 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 4144 > which port is undefined, or if all ports are allowed or > port is OPAQUE, this field MUST be zero. For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer (with Type in the most > significant eight bits and Code in the least significant > eight bits) port number for the purposes of filtering based > on this field. > .sp > o End Port (2 octets) - Value specifying the largest port > number allowed by this Traffic Selector. For protocols for > which port is undefined, or if all ports are allowed or > port is OPAQUE, this field MUST be 65535. For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer (with Type in the most > significant eight bits and Code in the least significant > eight bits) port number for the purposed of filtering based > on this field. > **************************************************** i040509.txt, Line > 4186 > which port is undefined, or if all ports and packets where > port is OPAQUE are allowed, this field MUST be zero. For > the ICMP protocol, the two one octet fields Type and Code > are treated as a single 16 bit integer (with Type in the > most significant eight bits and Code in the least > significant eight bits) port number for the purposes of > filtering based on this field. A Start Port value of 65535 > with an End Port value of 0 in a traffic selector indicates > non-initial IP fragments where the port is therefore OPAQUE. > Any other Traffic Selector where Start Port > End Port is > invalid, MUST NOT be sent, and MUST be ignored on receipt. > .sp > o End Port (2 octets) - Value specifying the largest port > number allowed by this Traffic Selector. For protocols for > which port is undefined, or if all ports and packets where > port is OPAQUE are allowed, this field MUST be 65535. For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer (with Type in the most > significant eight bits and Code in the least significant > eight bits) port number for the purposed of filtering based > on this field. A Start Port value of 65535 with an End Port > value of 0 in a traffic selector indicates non-initial IP > fragments where the port is therefore OPAQUE. Any other > Traffic Selector where Start Port > End Port is invalid, > MUST NOT be sent, and MUST be ignored on receipt. > > > > Issue #97 > ============================================================== > ========== > === > **************************************************** > i040322.txt, Line 4740 sufficient for use with 3DES. Groups > three through five provide greater security. Group one is for > historic purposes only and does not provide sufficient > strength except for use with DES, which is also for historic > use only. Implementations should make note of these > conservative estimates when establishing > **************************************************** i040509.txt, Line > 4806 > common for use with 3DES. Group five provides greater > security than group two. > Group one is for historic purposes only and does not provide > sufficient strength except for use with DES, which is also > for historic use only. Implementations should make note of > these estimates when establishing > > > > > Issue #100 > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 3426 > a chain of certificates. If a certificate exists which > satisfies the criteria specified in the Certificate Request > Payload, the certificate MUST be sent back to the certificate > requestor; if a certificate chain exists which goes back to > the certification authority specified in the request the > entire chain SHOULD be sent back to the certificate > requestor. If multiple certificates or chains exist that > satisfy the request, the sender MUST pick one. If no > certificates exist then the Certificate Request Payload is ignored. > This > is not an error condition of the protocol. There may be cases > where there is a preferred CA, but an alternate might be > acceptable (perhaps after prompting a human operator). > **************************************************** i040509.txt, Line > 3435 > a chain of certificates. > > If an end-entity certificate exists which satisfies the > criteria specified in the CERTREQ, a certificate or > certificate chain SHOULD be sent back to the certificate requestor if: > .sp > - the recipient of the CERTREQ is configured to use > certificate authentication, .sp > - is allowed to send a CERT payload, > .sp > - has matching CA trust policy governing the current > negotiation, and .sp > - has at least one time-wise and usage appropriate > end-entity certificate chaining to a CA provided in the CERTREQ. > .sp > Certificate revocation checking must be considered during the > chaining process used to select a certificate. Note that even > if two peers are configured to use two different CAs, > cross-certification relationships should be supported by > appropriate selection logic. The intent is not to prevent > communication through the strict adherence of selection of a > certificate based on CERTREQ, when an alternate certificate > could be selected by the sender which would still enable the > recipient to successfully validate and trust it through trust > conveyed by cross-certification, CRLs or other out-of-band > configured 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 condition of the protocol. > There may be cases where there is a preferred CA sent in the > CERTREQ, but an alternate might be acceptable (perhaps after > prompting a human operator)." > ============================================================== > ========== > === > **************************************************** i040322.txt, Line > 4727 > **************************************************** i040509.txt, Line > 4777 > While this protocol is designed to minimize disclosure of > configuration information to unauthenticated peers, some such > disclosure is unavoidable. > One peer or the other must identify itself first and prove > its identity first. > To avoid probing, the initiator of an exchange is required to > identify itself first, and usually is required to > authenticate itself first. The initiator can, however, learn > that the responder supports IKE and what cryptographic > protocols it supports. The responder (or someone > impersonating the responder) can probe the initiator not only > for its identity, but using CERTREQ payloads may be able to > determine what certificates the initiator is willing to use. > .sp > Use of EAP authentication changes the probing possibilities somewhat. > When > EAP authentication is used, the responder proves its identity > before the initiator does, so an initiator that knew the name > of a valid initiator could probe the responder for both its > name and certificates. > .sp > ============================================================== > ========== > === > **************************************************** > i040322.txt, Line 5010 > **************************************************** i040509.txt, Line > 5077 > > [RFC1958] Carpenter, B., "Architectural Principles of the > Internet", RFC 1958, June 1996. > ============================================================== > ========== > === > **************************************************** > i040322.txt, Line 5030 > [RFC2983] Black, D., "Differentiated Services and Tunnels", > RFC 2983, October 2000. > **************************************************** > i040509.txt, Line 5100 > [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, > February 2000. > > [RFC2983] Black, D., "Differentiated Services and Tunnels", > RFC 2983, October 2000. > > [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural > Guidelines and Philosophy", RFC 3429, December 2002. > > _______________________________________________ > 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-admin@ietf.org Mon May 24 00:05:31 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24825 for ; Mon, 24 May 2004 00:05:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6aD-0004RY-G2; Sun, 23 May 2004 23:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6XG-00043Q-BW for ipsec@optimus.ietf.org; Sun, 23 May 2004 23:53:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24549 for ; Sun, 23 May 2004 23:53:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS6XE-00067p-5O for ipsec@ietf.org; Sun, 23 May 2004 23:53:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6WF-0005qo-00 for ipsec@ietf.org; Sun, 23 May 2004 23:52:56 -0400 Received: from mail.esmartstart.com ([66.119.143.50] helo=mail.radioburst.com) by ietf-mx with esmtp (Exim 4.12) id 1BS6VD-0005L7-00 for ipsec@ietf.org; Sun, 23 May 2004 23:51:51 -0400 Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i4O3pAmD007976 for ; Sun, 23 May 2004 21:51:11 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i4O3nTHK019658 for ; Sun, 23 May 2004 21:49:35 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i4O3nTcl019654; Sun, 23 May 2004 21:49:29 -0600 Date: Sun, 23 May 2004 21:49:29 -0600 Message-Id: <200405240349.i4O3nTcl019654@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ipsec@ietf.org In-reply-to: Yourmessage <200405240058.i4O0w1rb026245@rs9.luxsci.com> Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 X-esmartscan-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , The risks that William Dixon mentions wrt to the exposure of sensitive information in certificates or certificate requests can be eliminated through the use of "Hidden Credentials". The HC method allows both sides (authenticatee and authenticator) in the authentication exchange to keep their requirements and credentials secret unless there is a match that will allow authentication to succeed. I presented this at an IPSec meeting a few IETF's ago. The only known implementation relies on Identity-Based Encryption (IBE) which is patented IPR, and IBE relies on elliptic curve groups, which have some associated IPR. Despite these drawbacks, Hidden Credentials do solve an important trust problem for protocols like IKE, and might be worth some thought for IKEng. Hilarie _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 00:16:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25204 for ; Mon, 24 May 2004 00:16:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6m2-0006QN-9C for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 00:09:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O49Ek6024690 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 00:09:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6ju-0005pt-8C for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 00:07:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24897 for ; Mon, 24 May 2004 00:06:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS6jr-0001pk-T2 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 00:06:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6is-0001YN-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 00:05:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS6hy-0001IG-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 00:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6aD-0004RY-G2; Sun, 23 May 2004 23:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS6XG-00043Q-BW for ipsec@optimus.ietf.org; Sun, 23 May 2004 23:53:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24549 for ; Sun, 23 May 2004 23:53:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS6XE-00067p-5O for ipsec@ietf.org; Sun, 23 May 2004 23:53:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS6WF-0005qo-00 for ipsec@ietf.org; Sun, 23 May 2004 23:52:56 -0400 Received: from mail.esmartstart.com ([66.119.143.50] helo=mail.radioburst.com) by ietf-mx with esmtp (Exim 4.12) id 1BS6VD-0005L7-00 for ipsec@ietf.org; Sun, 23 May 2004 23:51:51 -0400 Received: from localhost.localdomain (dav.rfburst.com [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i4O3pAmD007976 for ; Sun, 23 May 2004 21:51:11 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i4O3nTHK019658 for ; Sun, 23 May 2004 21:49:35 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i4O3nTcl019654; Sun, 23 May 2004 21:49:29 -0600 Date: Sun, 23 May 2004 21:49:29 -0600 Message-Id: <200405240349.i4O3nTcl019654@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ipsec@ietf.org In-reply-to: Yourmessage <200405240058.i4O0w1rb026245@rs9.luxsci.com> Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 X-esmartscan-MailScanner: Found to be clean Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 The risks that William Dixon mentions wrt to the exposure of sensitive information in certificates or certificate requests can be eliminated through the use of "Hidden Credentials". The HC method allows both sides (authenticatee and authenticator) in the authentication exchange to keep their requirements and credentials secret unless there is a match that will allow authentication to succeed. I presented this at an IPSec meeting a few IETF's ago. The only known implementation relies on Identity-Based Encryption (IBE) which is patented IPR, and IBE relies on elliptic curve groups, which have some associated IPR. Despite these drawbacks, Hidden Credentials do solve an important trust problem for protocols like IKE, and might be worth some thought for IKEng. Hilarie _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 01:06:34 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27418 for ; Mon, 24 May 2004 01:06:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7WH-0004GO-PC; Mon, 24 May 2004 00:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7TO-0003V5-Nu for ipsec@optimus.ietf.org; Mon, 24 May 2004 00:54:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26441 for ; Mon, 24 May 2004 00:53:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS7TL-0006eW-MD for ipsec@ietf.org; Mon, 24 May 2004 00:53:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS7SM-0006Np-00 for ipsec@ietf.org; Mon, 24 May 2004 00:52:59 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BS7RP-000674-00 for ipsec@ietf.org; Mon, 24 May 2004 00:51:59 -0400 Received: from 192.94.214.101 ([218.191.27.152]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i4O4oRo19565 for ; Mon, 24 May 2004 00:50:27 -0400 (EDT) Message-Id: <200405240450.i4O4oRo19565@lists.tislabs.com> X-Message-Info: NP1WQBPbet666okGUacVA2HSP59femDMMibY151 Received: from 71.12.143.75 by ip-66-4-829-6.hcx.ipsec@portal.gw.tislabs.com (AppleMailServer 83.7.1.5) id 7035163305 via NDR; Wed, 26 May 2004 00:55:46 -0500 Reply-To: "Bernardo Ferguson" From: "Bernardo Ferguson" To: "Ipsec" Date: Wed, 26 May 2004 08:56:46 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_sPxDWovdNqIy" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.6 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Subject: [Ipsec] Ipsec for 6321 but Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----=_sPxDWovdNqIy Content-Type: text/plain; charset="iso-6134-1" Content-Transfer-Encoding: 7Bit Ipsec, heres that info G-eneric v*i@gr@ at 80% Discount! Delivered world wide!( http://submitted.pilulka.biz/gv/index.php?pid=eph3404 S'v'p'e'r Vi^^agra(Cia`lis): http://atlantica.doctorhelps.com/sv/index.php?pid=eph3404 ocular nicotine derby upstart rich more worrisome peroxide vermilion refract oyster bakelite swelt dexter angles clarence peasant ringside bacon exodus ----=_sPxDWovdNqIy-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 01:19:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28136 for ; Mon, 24 May 2004 01:19:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7n5-0007ap-3C for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 01:14:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O5ENeG029183 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 01:14:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7gy-0005rJ-GW for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 01:08:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27521 for ; Mon, 24 May 2004 01:08:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS7gv-000383-IL for ipsec-web-archive@ietf.org; Mon, 24 May 2004 01:08:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS7fz-0002ob-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 01:07:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS7f1-0002WM-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 01:06:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7WH-0004GO-PC; Mon, 24 May 2004 00:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7TO-0003V5-Nu for ipsec@optimus.ietf.org; Mon, 24 May 2004 00:54:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26441 for ; Mon, 24 May 2004 00:53:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS7TL-0006eW-MD for ipsec@ietf.org; Mon, 24 May 2004 00:53:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS7SM-0006Np-00 for ipsec@ietf.org; Mon, 24 May 2004 00:52:59 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BS7RP-000674-00 for ipsec@ietf.org; Mon, 24 May 2004 00:51:59 -0400 Received: from 192.94.214.101 ([218.191.27.152]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i4O4oRo19565 for ; Mon, 24 May 2004 00:50:27 -0400 (EDT) Message-Id: <200405240450.i4O4oRo19565@lists.tislabs.com> X-Message-Info: NP1WQBPbet666okGUacVA2HSP59femDMMibY151 Received: from 71.12.143.75 by ip-66-4-829-6.hcx.ipsec@portal.gw.tislabs.com (AppleMailServer 83.7.1.5) id 7035163305 via NDR; Wed, 26 May 2004 00:55:46 -0500 Reply-To: "Bernardo Ferguson" From: "Bernardo Ferguson" To: "Ipsec" Date: Wed, 26 May 2004 08:56:46 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_sPxDWovdNqIy" Subject: [Ipsec] Ipsec for 6321 but Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.6 required=5.0 tests=BIZ_TLD,FORGED_RCVD_NET_HELO, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 ----=_sPxDWovdNqIy Content-Type: text/plain; charset="iso-6134-1" Content-Transfer-Encoding: 7Bit Ipsec, heres that info G-eneric v*i@gr@ at 80% Discount! Delivered world wide!( http://submitted.pilulka.biz/gv/index.php?pid=eph3404 S'v'p'e'r Vi^^agra(Cia`lis): http://atlantica.doctorhelps.com/sv/index.php?pid=eph3404 ocular nicotine derby upstart rich more worrisome peroxide vermilion refract oyster bakelite swelt dexter angles clarence peasant ringside bacon exodus ----=_sPxDWovdNqIy-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 02:08:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08175 for ; Mon, 24 May 2004 02:08:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8XJ-000535-A5; Mon, 24 May 2004 02:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8Op-000443-1A for ipsec@optimus.ietf.org; Mon, 24 May 2004 01:53:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29451 for ; Mon, 24 May 2004 01:53:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS8Ol-000089-PH for ipsec@ietf.org; Mon, 24 May 2004 01:53:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8Nf-0007eG-00 for ipsec@ietf.org; Mon, 24 May 2004 01:52:12 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BS8NK-0007NH-00 for ipsec@ietf.org; Mon, 24 May 2004 01:51:50 -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 i4O5oJo02888 for ; Mon, 24 May 2004 01:50:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4O5nHAg027768 for ; Mon, 24 May 2004 01:49:17 -0400 (EDT) Received: from unknown(203.199.214.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPLaqm2; Mon, 24 May 04 01:49:11 -0400 Date: Mon, 24 May 2004 11:12:08 +0530 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zbkoqhezwofpyjllklwr" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Notification Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------zbkoqhezwofpyjllklwr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------zbkoqhezwofpyjllklwr Content-Type: text/html; name="Your_money.scr.htm" Content-Disposition: attachment; filename="Your_money.scr.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: Your_money.scr
Virus name: W32/Bagle.aa@MM

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

----------zbkoqhezwofpyjllklwr-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 02:13:11 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13023 for ; Mon, 24 May 2004 02:13:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8gl-0007GO-5h for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 02:11:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O6Bthg027921 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 02:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8eJ-0006ff-GJ for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 02:09:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09313 for ; Mon, 24 May 2004 02:09:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS8eF-0004ju-9V for ipsec-web-archive@ietf.org; Mon, 24 May 2004 02:09:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8dB-0004Qk-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 02:08:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS8cg-00048y-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 02:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8XJ-000535-A5; Mon, 24 May 2004 02:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS8Op-000443-1A for ipsec@optimus.ietf.org; Mon, 24 May 2004 01:53:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29451 for ; Mon, 24 May 2004 01:53:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS8Ol-000089-PH for ipsec@ietf.org; Mon, 24 May 2004 01:53:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS8Nf-0007eG-00 for ipsec@ietf.org; Mon, 24 May 2004 01:52:12 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BS8NK-0007NH-00 for ipsec@ietf.org; Mon, 24 May 2004 01:51:50 -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 i4O5oJo02888 for ; Mon, 24 May 2004 01:50:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4O5nHAg027768 for ; Mon, 24 May 2004 01:49:17 -0400 (EDT) Received: from unknown(203.199.214.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPLaqm2; Mon, 24 May 04 01:49:11 -0400 Date: Mon, 24 May 2004 11:12:08 +0530 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zbkoqhezwofpyjllklwr" Subject: [Ipsec] Notification Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------zbkoqhezwofpyjllklwr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------zbkoqhezwofpyjllklwr Content-Type: text/html; name="Your_money.scr.htm" Content-Disposition: attachment; filename="Your_money.scr.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: Your_money.scr
Virus name: W32/Bagle.aa@MM

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

----------zbkoqhezwofpyjllklwr-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 02:56:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15713 for ; Mon, 24 May 2004 02:56:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9Fi-0004zq-1U; Mon, 24 May 2004 02:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9Cs-0004W8-UU for ipsec@optimus.ietf.org; Mon, 24 May 2004 02:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15204 for ; Mon, 24 May 2004 02:45:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS9Cp-0006z6-7N for ipsec@ietf.org; Mon, 24 May 2004 02:45:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS9Br-0006iw-00 for ipsec@ietf.org; Mon, 24 May 2004 02:44:04 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BS9Ay-0006S4-00 for ipsec@ietf.org; Mon, 24 May 2004 02:43:08 -0400 Received: from adsl-69-107-95-131.dsl.pltn13.pacbell.net ([69.107.95.131] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BS9As-0002Hy-00; Mon, 24 May 2004 02:43:03 -0400 Received: from root by thunk.org with local (Exim 4.34) id 1BS7o1-0002Qe-TZ; Mon, 24 May 2004 01:15:21 -0400 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Mon, 24 May 2004 01:15:21 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , There has been quite a bit of discussion on the ipsec wg mailing list concerning how IPSEC (The Next Generation) should handle fragmentation in tunnel mode. The controversy has been over what sort of support IPSEC implementations should have for supporting policies that require the use of different SA's based on the TCP or UDP port of the packet in question. Now, to keep things in perspective, I should note here at this point that it's not clear how many (if any) implementations actually support per-port SA's in tunnel mode, and if any end-users would actually find this useful in practice. The text in question can be found in section 7 of draft-ietf-rfc2401bis-02.txt. Method #1 in section 7 describes how fragmentation in tunnel mode should work in the case when the SA's have been configured to pass without regard to port number, ICMP type/code, or Mobility Header type. This is a fairly simple case, and there is working group consensus this a MUST implement. (It also is what I suspect 99.97% users are using today.) Methods #2 and #3 describe different ways of supporting the fragments in tunnel mode when there is a desire to have SA's that differentiate on the basis of port number, ICMP type/code, etc. Method #2 specifies that non-initial fragments should be sent to a separate SA (which is designated to receive packets with OPAQUE port numbers). This method is ideal for high-speed IPSEC implementations (that still want to support per-port SA's as well as fragments). Method #3 specifies that implementation perform what is essentially stateful fragment inspection so that fragments can be dispatched to the correct SA. This method is needed if it is a requirement to enforce policies where all data sent to certain ports MUST be encrypted, while all data sent to other ports MUST NOT be encrypt, but perhaps only integrit protected. The question before the IPSEC working group is then whether Methods #2 and #3 should be a MAY, SHOULD, or MUST implement. Since there are multiple choices before us, let me try to approach this question from a different directions: Some people have argued that both should be MAY; presumably these are people who are not conviced of the utility of having per-port SA's in tunnel mode. Others have expressed the belief that at least one of Method #2 or #3 should be mandatory to implement, so that there is some way of interoperably way of supporting per-port SA's and fragmentation at the same time. QUESTION 1: Select one of the following ____ Both Methods #2 and Method #3 should be a MAY ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST ___ Method #2 (non-initial fragments get sent to an OPAQUE SA) should be be SHOULD or MUST ___ Method #3 (stateful fragment inspection) should be SHOULD or MUST) ___ Both Method #2 and #3 should be SHOULD or MUST Another point which has been discussed is how difficult it is to implement stateful fragment inspection. Tero has pointed out that his implementation has supported this for quite some time, and it isn't particularly difficult. Steve Kent has expressed a concern that requiring stateful packet inspection might be too much of a burden for high speed implementation. Steve was willing to compromise with a Method #3 being a SHOULD, since that would still give wiggle room for implementations to not implement #3. Others have been concerned that many other implementations have not implemented stateful fragment inspection, and it might be too burdensome even to strongly encourage implementation of Method #3 by making it a SHOULD. (In contrast, method #2 is very easy to implement, although it is admittedly less featureful than #3.) QUESTION 2: Should Method #2 (non-initial fragments) be: (you may pick more than one) ___ MUST ___ SHOULD ___ MAY QUESTION 3: Should Method #3 (stateful fragment inspection) be: (you may pick more than one) ___ MUST ___ SHOULD ___ MAY Please respond to this straw poll by the end of this week (May 28th). - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 03:08:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16014 for ; Mon, 24 May 2004 03:08:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9XC-0007FT-7O for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 03:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O766DB027862 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 03:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9Ob-0006AR-T1 for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 02:57:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15738 for ; Mon, 24 May 2004 02:57:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS9OX-0002dB-W9 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 02:57:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS9Nc-0002Ml-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 02:56:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS9NI-00026O-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 02:55:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9Fi-0004zq-1U; Mon, 24 May 2004 02:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS9Cs-0004W8-UU for ipsec@optimus.ietf.org; Mon, 24 May 2004 02:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15204 for ; Mon, 24 May 2004 02:45:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS9Cp-0006z6-7N for ipsec@ietf.org; Mon, 24 May 2004 02:45:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS9Br-0006iw-00 for ipsec@ietf.org; Mon, 24 May 2004 02:44:04 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BS9Ay-0006S4-00 for ipsec@ietf.org; Mon, 24 May 2004 02:43:08 -0400 Received: from adsl-69-107-95-131.dsl.pltn13.pacbell.net ([69.107.95.131] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BS9As-0002Hy-00; Mon, 24 May 2004 02:43:03 -0400 Received: from root by thunk.org with local (Exim 4.34) id 1BS7o1-0002Qe-TZ; Mon, 24 May 2004 01:15:21 -0400 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Mon, 24 May 2004 01:15:21 -0400 Subject: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 There has been quite a bit of discussion on the ipsec wg mailing list concerning how IPSEC (The Next Generation) should handle fragmentation in tunnel mode. The controversy has been over what sort of support IPSEC implementations should have for supporting policies that require the use of different SA's based on the TCP or UDP port of the packet in question. Now, to keep things in perspective, I should note here at this point that it's not clear how many (if any) implementations actually support per-port SA's in tunnel mode, and if any end-users would actually find this useful in practice. The text in question can be found in section 7 of draft-ietf-rfc2401bis-02.txt. Method #1 in section 7 describes how fragmentation in tunnel mode should work in the case when the SA's have been configured to pass without regard to port number, ICMP type/code, or Mobility Header type. This is a fairly simple case, and there is working group consensus this a MUST implement. (It also is what I suspect 99.97% users are using today.) Methods #2 and #3 describe different ways of supporting the fragments in tunnel mode when there is a desire to have SA's that differentiate on the basis of port number, ICMP type/code, etc. Method #2 specifies that non-initial fragments should be sent to a separate SA (which is designated to receive packets with OPAQUE port numbers). This method is ideal for high-speed IPSEC implementations (that still want to support per-port SA's as well as fragments). Method #3 specifies that implementation perform what is essentially stateful fragment inspection so that fragments can be dispatched to the correct SA. This method is needed if it is a requirement to enforce policies where all data sent to certain ports MUST be encrypted, while all data sent to other ports MUST NOT be encrypt, but perhaps only integrit protected. The question before the IPSEC working group is then whether Methods #2 and #3 should be a MAY, SHOULD, or MUST implement. Since there are multiple choices before us, let me try to approach this question from a different directions: Some people have argued that both should be MAY; presumably these are people who are not conviced of the utility of having per-port SA's in tunnel mode. Others have expressed the belief that at least one of Method #2 or #3 should be mandatory to implement, so that there is some way of interoperably way of supporting per-port SA's and fragmentation at the same time. QUESTION 1: Select one of the following ____ Both Methods #2 and Method #3 should be a MAY ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST ___ Method #2 (non-initial fragments get sent to an OPAQUE SA) should be be SHOULD or MUST ___ Method #3 (stateful fragment inspection) should be SHOULD or MUST) ___ Both Method #2 and #3 should be SHOULD or MUST Another point which has been discussed is how difficult it is to implement stateful fragment inspection. Tero has pointed out that his implementation has supported this for quite some time, and it isn't particularly difficult. Steve Kent has expressed a concern that requiring stateful packet inspection might be too much of a burden for high speed implementation. Steve was willing to compromise with a Method #3 being a SHOULD, since that would still give wiggle room for implementations to not implement #3. Others have been concerned that many other implementations have not implemented stateful fragment inspection, and it might be too burdensome even to strongly encourage implementation of Method #3 by making it a SHOULD. (In contrast, method #2 is very easy to implement, although it is admittedly less featureful than #3.) QUESTION 2: Should Method #2 (non-initial fragments) be: (you may pick more than one) ___ MUST ___ SHOULD ___ MAY QUESTION 3: Should Method #3 (stateful fragment inspection) be: (you may pick more than one) ___ MUST ___ SHOULD ___ MAY Please respond to this straw poll by the end of this week (May 28th). - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 05:17:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21939 for ; Mon, 24 May 2004 05:17:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBRN-0005Gl-7D; Mon, 24 May 2004 05:08:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBKf-0004ZD-Km for ipsec@optimus.ietf.org; Mon, 24 May 2004 05:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21292 for ; Mon, 24 May 2004 05:01:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSBKc-0000AK-E9 for ipsec@ietf.org; Mon, 24 May 2004 05:01:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBJk-0007fT-00 for ipsec@ietf.org; Mon, 24 May 2004 05:00:21 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BSBIp-0007ND-00 for ipsec@ietf.org; Mon, 24 May 2004 04:59:23 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4O8xMGQ003052 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 May 2004 11:59:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4O8xLgm003049; Mon, 24 May 2004 11:59:21 +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: <16561.47465.22.497488@fireball.kivinen.iki.fi> Date: Mon, 24 May 2004 11:59:20 +0300 From: Tero Kivinen To: "William Dixon" Cc: "'Charlie Kaufman'" , Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 In-Reply-To: <200405240058.i4O0w1rb026245@rs9.luxsci.com> References: <200405240058.i4O0w1rb026245@rs9.luxsci.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 6 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit William Dixon writes: > To the text quoted above, the optional CERTREQ from the responder reveals > the trust anchors that the unauthenticated responder would presumably use to > authenticate the initiator. Certain usages of the CERTREQ payload (by > default for example) in products may inadvertently increase the risk to the > customer. The risk is when the CERTREQ contains a DN of a CA name that > identifies the organizational owner of the gateway, and certainly which > trust infrastructure must be compromised. This could provide important > information to the attacker if the CA name were the lowest level of issuing > authority for which a certificate was accepted (such as "Defense Nuclear > Analysis Branch Issuing CA"), or perhaps generally useful but less specific > information if the CA DN name were the root CA name (such as "Defense Dept > Root CA"). The use of PKI technology and certain privately owned PKIs for > IKEv2 may not in fact be something that is intended to be known or > advertised publicly. Thus it may be necessary to rely solely upon initiator > configuration or user selection to know which certificate to offer. NOte, that in IKEv2 the DN of the CA is NOT sent. The Certificate request payload contains SHA-1 hashes of the public keys of trusted CAs. So when the attacker see that the initiator trust CA "94ea1e00fb5e85fea5e645aab20fb408dce3c4b1" (in binary), it is little hard to know which CA it actually trusts unless you already know the CA public key. So without seeing the actual certificate you cannot know which CA it trust. You can however still track that this client uses the same CA than that other client.... If we would want to hide that information too, we would be required to add IKE-SPIs to the hash, i.e defiene that the SHA-1 hashes CERTREQ are HMAC keyed hash using the IKE-SPI of the hash of the public key, or similar (i.e. CERTREQ_PAYLOAD = HMAC(IKE_SA initoator SPI, SAH-1 hash of the public key of CA). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 05:25:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22155 for ; Mon, 24 May 2004 05:25:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBW8-0005wl-KX; Mon, 24 May 2004 05:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBNg-0004nB-7T for ipsec@optimus.ietf.org; Mon, 24 May 2004 05:04:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21352 for ; Mon, 24 May 2004 05:04:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSBNc-00012i-U4 for ipsec@ietf.org; Mon, 24 May 2004 05:04:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBMk-0000kG-00 for ipsec@ietf.org; Mon, 24 May 2004 05:03:27 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BSBLs-0000CL-00 for ipsec@ietf.org; Mon, 24 May 2004 05:02:32 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4O921C13081; Mon, 24 May 2004 12:02:01 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02F3E0FC-AD61-11D8-9471-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org From: Yoav Nir Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Date: Mon, 24 May 2004 12:01:58 +0300 To: "Theodore Ts'o" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm one of those people who don't see the utility of having per-port SAs, so I vote for MAY for both #2 and #3. I see port selection as firewall function rather than an encryption function. #1 is IMO even better suited for high-speed implementations than #2. #2 means that fragments are easy to spot (the distribution of lengths and times for the special SA will be different from other SAs), and that reveals information that we don't want to reveal. #3 can be done by many implementations, and I personally would not mind seeing it become a SHOULD. For interoperability, though, I would hesitate to send fragments through a per-port SA when I don't know for sure that the other side knows how to do stateful inspection. On May 24, 2004, at 8:15 AM, Theodore Ts'o wrote: > > There has been quite a bit of discussion on the ipsec wg mailing list > concerning how IPSEC (The Next Generation) should handle fragmentation > in tunnel mode. The controversy has been over what sort of support > IPSEC implementations should have for supporting policies that require > the use of different SA's based on the TCP or UDP port of the packet in > question. Now, to keep things in perspective, I should note here at > this point that it's not clear how many (if any) implementations > actually support per-port SA's in tunnel mode, and if any end-users > would actually find this useful in practice. > > The text in question can be found in section 7 of > draft-ietf-rfc2401bis-02.txt. Method #1 in section 7 describes how > fragmentation in tunnel mode should work in the case when the SA's have > been configured to pass without regard to port number, ICMP type/code, > or Mobility Header type. This is a fairly simple case, and there is > working group consensus this a MUST implement. (It also is what I > suspect 99.97% users are using today.) > > Methods #2 and #3 describe different ways of supporting the fragments > in > tunnel mode when there is a desire to have SA's that differentiate on > the basis of port number, ICMP type/code, etc. Method #2 specifies > that > non-initial fragments should be sent to a separate SA (which is > designated to receive packets with OPAQUE port numbers). This method > is ideal for high-speed IPSEC implementations (that still want to > support per-port SA's as well as fragments). > > Method #3 specifies that implementation perform what is essentially > stateful fragment inspection so that fragments can be dispatched to the > correct SA. This method is needed if it is a requirement to enforce > policies where all data sent to certain ports MUST be encrypted, while > all data sent to other ports MUST NOT be encrypt, but perhaps only > integrit protected. > > The question before the IPSEC working group is then whether Methods #2 > and #3 should be a MAY, SHOULD, or MUST implement. Since there are > multiple choices before us, let me try to approach this question from a > different directions: > > > Some people have argued that both should be MAY; presumably these are > people who are not conviced of the utility of having per-port SA's in > tunnel mode. Others have expressed the belief that at least one of > Method #2 or #3 should be mandatory to implement, so that there is some > way of interoperably way of supporting per-port SA's and fragmentation > at the same time. > > QUESTION 1: Select one of the following > > ____ Both Methods #2 and Method #3 should be a MAY > > ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST > > ___ Method #2 (non-initial fragments get sent to an OPAQUE > SA) should be be SHOULD or MUST > > ___ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > ___ Both Method #2 and #3 should be SHOULD or MUST > > > Another point which has been discussed is how difficult it is to > implement stateful fragment inspection. Tero has pointed out that his > implementation has supported this for quite some time, and it isn't > particularly difficult. Steve Kent has expressed a concern that > requiring stateful packet inspection might be too much of a burden for > high speed implementation. Steve was willing to compromise with a > Method #3 being a SHOULD, since that would still give wiggle room for > implementations to not implement #3. Others have been concerned that > many other implementations have not implemented stateful fragment > inspection, and it might be too burdensome even to strongly encourage > implementation of Method #3 by making it a SHOULD. > > (In contrast, method #2 is very easy to implement, although it is > admittedly less featureful than #3.) > > QUESTION 2: Should Method #2 (non-initial fragments) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > ___ MAY > > > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > ___ MAY > > > Please respond to this straw poll by the end of this week (May 28th). > > - Ted > > _______________________________________________ > 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 exim@www1.ietf.org Mon May 24 05:28:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22335 for ; Mon, 24 May 2004 05:28:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBjI-0007do-R6 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 05:26:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O9QiNE029368 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 05:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBbD-0006ec-0y for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 05:18:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22003 for ; Mon, 24 May 2004 05:18:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSBb9-0005Bc-MJ for ipsec-web-archive@ietf.org; Mon, 24 May 2004 05:18:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBaI-0004tu-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 05:17:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSBZh-0004bM-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 05:16:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBRN-0005Gl-7D; Mon, 24 May 2004 05:08:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBKf-0004ZD-Km for ipsec@optimus.ietf.org; Mon, 24 May 2004 05:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21292 for ; Mon, 24 May 2004 05:01:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSBKc-0000AK-E9 for ipsec@ietf.org; Mon, 24 May 2004 05:01:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBJk-0007fT-00 for ipsec@ietf.org; Mon, 24 May 2004 05:00:21 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BSBIp-0007ND-00 for ipsec@ietf.org; Mon, 24 May 2004 04:59:23 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4O8xMGQ003052 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 May 2004 11:59:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4O8xLgm003049; Mon, 24 May 2004 11:59:21 +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: <16561.47465.22.497488@fireball.kivinen.iki.fi> Date: Mon, 24 May 2004 11:59:20 +0300 From: Tero Kivinen To: "William Dixon" Cc: "'Charlie Kaufman'" , Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 In-Reply-To: <200405240058.i4O0w1rb026245@rs9.luxsci.com> References: <200405240058.i4O0w1rb026245@rs9.luxsci.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 6 min Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit William Dixon writes: > To the text quoted above, the optional CERTREQ from the responder reveals > the trust anchors that the unauthenticated responder would presumably use to > authenticate the initiator. Certain usages of the CERTREQ payload (by > default for example) in products may inadvertently increase the risk to the > customer. The risk is when the CERTREQ contains a DN of a CA name that > identifies the organizational owner of the gateway, and certainly which > trust infrastructure must be compromised. This could provide important > information to the attacker if the CA name were the lowest level of issuing > authority for which a certificate was accepted (such as "Defense Nuclear > Analysis Branch Issuing CA"), or perhaps generally useful but less specific > information if the CA DN name were the root CA name (such as "Defense Dept > Root CA"). The use of PKI technology and certain privately owned PKIs for > IKEv2 may not in fact be something that is intended to be known or > advertised publicly. Thus it may be necessary to rely solely upon initiator > configuration or user selection to know which certificate to offer. NOte, that in IKEv2 the DN of the CA is NOT sent. The Certificate request payload contains SHA-1 hashes of the public keys of trusted CAs. So when the attacker see that the initiator trust CA "94ea1e00fb5e85fea5e645aab20fb408dce3c4b1" (in binary), it is little hard to know which CA it actually trusts unless you already know the CA public key. So without seeing the actual certificate you cannot know which CA it trust. You can however still track that this client uses the same CA than that other client.... If we would want to hide that information too, we would be required to add IKE-SPIs to the hash, i.e defiene that the SHA-1 hashes CERTREQ are HMAC keyed hash using the IKE-SPI of the hash of the public key, or similar (i.e. CERTREQ_PAYLOAD = HMAC(IKE_SA initoator SPI, SAH-1 hash of the public key of CA). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 05:35:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22574 for ; Mon, 24 May 2004 05:35:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBkQ-00082p-6b for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 05:27:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O9Rsvq030915 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 05:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBiw-0007aO-AO for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 05:26:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22222 for ; Mon, 24 May 2004 05:26:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSBis-0007b0-R1 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 05:26:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBi6-0007IV-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 05:25:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSBhO-0006ze-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 05:24:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBW8-0005wl-KX; Mon, 24 May 2004 05:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBNg-0004nB-7T for ipsec@optimus.ietf.org; Mon, 24 May 2004 05:04:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21352 for ; Mon, 24 May 2004 05:04:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSBNc-00012i-U4 for ipsec@ietf.org; Mon, 24 May 2004 05:04:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBMk-0000kG-00 for ipsec@ietf.org; Mon, 24 May 2004 05:03:27 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BSBLs-0000CL-00 for ipsec@ietf.org; Mon, 24 May 2004 05:02:32 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4O921C13081; Mon, 24 May 2004 12:02:01 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02F3E0FC-AD61-11D8-9471-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org From: Yoav Nir Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Date: Mon, 24 May 2004 12:01:58 +0300 To: "Theodore Ts'o" X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm one of those people who don't see the utility of having per-port SAs, so I vote for MAY for both #2 and #3. I see port selection as firewall function rather than an encryption function. #1 is IMO even better suited for high-speed implementations than #2. #2 means that fragments are easy to spot (the distribution of lengths and times for the special SA will be different from other SAs), and that reveals information that we don't want to reveal. #3 can be done by many implementations, and I personally would not mind seeing it become a SHOULD. For interoperability, though, I would hesitate to send fragments through a per-port SA when I don't know for sure that the other side knows how to do stateful inspection. On May 24, 2004, at 8:15 AM, Theodore Ts'o wrote: > > There has been quite a bit of discussion on the ipsec wg mailing list > concerning how IPSEC (The Next Generation) should handle fragmentation > in tunnel mode. The controversy has been over what sort of support > IPSEC implementations should have for supporting policies that require > the use of different SA's based on the TCP or UDP port of the packet in > question. Now, to keep things in perspective, I should note here at > this point that it's not clear how many (if any) implementations > actually support per-port SA's in tunnel mode, and if any end-users > would actually find this useful in practice. > > The text in question can be found in section 7 of > draft-ietf-rfc2401bis-02.txt. Method #1 in section 7 describes how > fragmentation in tunnel mode should work in the case when the SA's have > been configured to pass without regard to port number, ICMP type/code, > or Mobility Header type. This is a fairly simple case, and there is > working group consensus this a MUST implement. (It also is what I > suspect 99.97% users are using today.) > > Methods #2 and #3 describe different ways of supporting the fragments > in > tunnel mode when there is a desire to have SA's that differentiate on > the basis of port number, ICMP type/code, etc. Method #2 specifies > that > non-initial fragments should be sent to a separate SA (which is > designated to receive packets with OPAQUE port numbers). This method > is ideal for high-speed IPSEC implementations (that still want to > support per-port SA's as well as fragments). > > Method #3 specifies that implementation perform what is essentially > stateful fragment inspection so that fragments can be dispatched to the > correct SA. This method is needed if it is a requirement to enforce > policies where all data sent to certain ports MUST be encrypted, while > all data sent to other ports MUST NOT be encrypt, but perhaps only > integrit protected. > > The question before the IPSEC working group is then whether Methods #2 > and #3 should be a MAY, SHOULD, or MUST implement. Since there are > multiple choices before us, let me try to approach this question from a > different directions: > > > Some people have argued that both should be MAY; presumably these are > people who are not conviced of the utility of having per-port SA's in > tunnel mode. Others have expressed the belief that at least one of > Method #2 or #3 should be mandatory to implement, so that there is some > way of interoperably way of supporting per-port SA's and fragmentation > at the same time. > > QUESTION 1: Select one of the following > > ____ Both Methods #2 and Method #3 should be a MAY > > ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST > > ___ Method #2 (non-initial fragments get sent to an OPAQUE > SA) should be be SHOULD or MUST > > ___ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > ___ Both Method #2 and #3 should be SHOULD or MUST > > > Another point which has been discussed is how difficult it is to > implement stateful fragment inspection. Tero has pointed out that his > implementation has supported this for quite some time, and it isn't > particularly difficult. Steve Kent has expressed a concern that > requiring stateful packet inspection might be too much of a burden for > high speed implementation. Steve was willing to compromise with a > Method #3 being a SHOULD, since that would still give wiggle room for > implementations to not implement #3. Others have been concerned that > many other implementations have not implemented stateful fragment > inspection, and it might be too burdensome even to strongly encourage > implementation of Method #3 by making it a SHOULD. > > (In contrast, method #2 is very easy to implement, although it is > admittedly less featureful than #3.) > > QUESTION 2: Should Method #2 (non-initial fragments) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > ___ MAY > > > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > ___ MAY > > > Please respond to this straw poll by the end of this week (May 28th). > > - Ted > > _______________________________________________ > 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-admin@ietf.org Mon May 24 08:04:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00144 for ; Mon, 24 May 2004 08:04:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSE1q-0002L0-UV; Mon, 24 May 2004 07:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDlh-0000Gv-3b for ipsec@optimus.ietf.org; Mon, 24 May 2004 07:37:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28512 for ; Mon, 24 May 2004 07:37:19 -0400 (EDT) From: Mika.Joutsenvirta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDlg-0002YZ-5w for ipsec@ietf.org; Mon, 24 May 2004 07:37:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDkg-0002Ff-00 for ipsec@ietf.org; Mon, 24 May 2004 07:36:19 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BSDjg-0001qn-00 for ipsec@ietf.org; Mon, 24 May 2004 07:35:16 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4OBZDE17944 for ; Mon, 24 May 2004 14:35:13 +0300 (EET DST) X-Scanned: Mon, 24 May 2004 14:34:52 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4OBYqjG006908 for ; Mon, 24 May 2004 14:34:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ycraL8; Mon, 24 May 2004 14:34:50 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4OBYoH23314 for ; Mon, 24 May 2004 14:34:50 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 14:34:45 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 14:34:45 +0300 Received: from trebe001.NOE.Nokia.com ([172.22.232.171]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 14:34:44 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 24 May 2004 14:34:44 +0300 Message-ID: <745CAFCB000ABE4588C309477108B50E02962BC7@trebe001.europe.nokia.com> Thread-Topic: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Thread-Index: AcRBW5t0tV7rTfHfTRyyKk6jI0TsQAABspKA To: X-OriginalArrivalTime: 24 May 2004 11:34:44.0681 (UTC) FILETIME=[1C6F8B90:01C44183] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Fragmentation of IPv6 tunneled packets Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I am going through fragmentation issues in IPv6 and there is one = question=20 that I would like to ask. Lets assume that host A sends 5KB UDP packet to host B and uses IPSec tunnel via SGW C. In this case=20 IPSec implementation in host A receives full 5KB UDP packet, encrypts the packet (IPSec ESP tunnel) and then fragments it to several = fragments and send the fragments to SGW C. SGW C reassembles fragments, decrypts IPSec ESP and tries to forward original 5KB UDP packet to host B.=20 But if IPv6 is used in this scenario, SGW C is not allowed to fragment=20 the UDP packet, but it should send ICMP "packet too big" to host A.=20 As general rule it seems to be that packet should be first IPSec = protected and then fragmented, but in this case it seems to lead to problems.=20 So should the SGW fragment the packet and forward the fragments to host = B or should the host A fragment packet before doing IPSec tunnel to it? Mika _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 08:31:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01840 for ; Mon, 24 May 2004 08:31:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSES6-0006ZE-Jg; Mon, 24 May 2004 08:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEFg-00058Z-9V for ipsec@optimus.ietf.org; Mon, 24 May 2004 08:08:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00469 for ; Mon, 24 May 2004 08:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEFf-0005ID-8E for ipsec@ietf.org; Mon, 24 May 2004 08:08:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEEg-0004z6-00 for ipsec@ietf.org; Mon, 24 May 2004 08:07:19 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BSEDb-0004Px-00 for ipsec@ietf.org; Mon, 24 May 2004 08:06:11 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4OC5wGQ004921 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 May 2004 15:05:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4OC5vF1004918; Mon, 24 May 2004 15:05:57 +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: <16561.58661.151824.536115@fireball.kivinen.iki.fi> Date: Mon, 24 May 2004 15:05:57 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: Stephen Kent , ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 In-Reply-To: References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > To address the above requirements, three approaches have been > defined. Implementations MUST support method #1 below, and SHOULD > support method #2 or method #3 (or both). I can also live with that proposal.... > Editorial suggestion: breaking out the three proposals as subsections > (7.1, 7.2, 7.3) would make it easier to read, particularly if you add > more text to them. Definately. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 08:45:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02427 for ; Mon, 24 May 2004 08:45:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEj1-0000oC-Qx for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 08:38:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OCcdeV003104 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 08:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSETu-00077T-6E for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 08:23:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01342 for ; Mon, 24 May 2004 08:22:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSETt-0001sj-53 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 08:23:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSESf-0001T0-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 08:21:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BSERD-0000rp-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 08:20:15 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BSEBH-000729-NV for ipsec-web-archive@ietf.org; Mon, 24 May 2004 08:03:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSE1q-0002L0-UV; Mon, 24 May 2004 07:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDlh-0000Gv-3b for ipsec@optimus.ietf.org; Mon, 24 May 2004 07:37:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28512 for ; Mon, 24 May 2004 07:37:19 -0400 (EDT) From: Mika.Joutsenvirta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDlg-0002YZ-5w for ipsec@ietf.org; Mon, 24 May 2004 07:37:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDkg-0002Ff-00 for ipsec@ietf.org; Mon, 24 May 2004 07:36:19 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BSDjg-0001qn-00 for ipsec@ietf.org; Mon, 24 May 2004 07:35:16 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4OBZDE17944 for ; Mon, 24 May 2004 14:35:13 +0300 (EET DST) X-Scanned: Mon, 24 May 2004 14:34:52 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4OBYqjG006908 for ; Mon, 24 May 2004 14:34:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ycraL8; Mon, 24 May 2004 14:34:50 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4OBYoH23314 for ; Mon, 24 May 2004 14:34:50 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 14:34:45 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 14:34:45 +0300 Received: from trebe001.NOE.Nokia.com ([172.22.232.171]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 14:34:44 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 24 May 2004 14:34:44 +0300 Message-ID: <745CAFCB000ABE4588C309477108B50E02962BC7@trebe001.europe.nokia.com> Thread-Topic: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Thread-Index: AcRBW5t0tV7rTfHfTRyyKk6jI0TsQAABspKA To: X-OriginalArrivalTime: 24 May 2004 11:34:44.0681 (UTC) FILETIME=[1C6F8B90:01C44183] Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Fragmentation of IPv6 tunneled packets Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I am going through fragmentation issues in IPv6 and there is one = question=20 that I would like to ask. Lets assume that host A sends 5KB UDP packet to host B and uses IPSec tunnel via SGW C. In this case=20 IPSec implementation in host A receives full 5KB UDP packet, encrypts the packet (IPSec ESP tunnel) and then fragments it to several = fragments and send the fragments to SGW C. SGW C reassembles fragments, decrypts IPSec ESP and tries to forward original 5KB UDP packet to host B.=20 But if IPv6 is used in this scenario, SGW C is not allowed to fragment=20 the UDP packet, but it should send ICMP "packet too big" to host A.=20 As general rule it seems to be that packet should be first IPSec = protected and then fragmented, but in this case it seems to lead to problems.=20 So should the SGW fragment the packet and forward the fragments to host = B or should the host A fragment packet before doing IPSec tunnel to it? Mika _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 08:54:23 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02905 for ; Mon, 24 May 2004 08:54:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEoj-00026c-MN for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 08:44:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OCiX8j008089 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 08:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEdu-0008PN-U3 for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 08:33:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01920 for ; Mon, 24 May 2004 08:33:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEdt-0005DT-Le for ipsec-web-archive@ietf.org; Mon, 24 May 2004 08:33:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEcw-0004v0-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 08:32:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSEbt-0004Wv-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 08:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSES6-0006ZE-Jg; Mon, 24 May 2004 08:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEFg-00058Z-9V for ipsec@optimus.ietf.org; Mon, 24 May 2004 08:08:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00469 for ; Mon, 24 May 2004 08:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEFf-0005ID-8E for ipsec@ietf.org; Mon, 24 May 2004 08:08:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEEg-0004z6-00 for ipsec@ietf.org; Mon, 24 May 2004 08:07:19 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BSEDb-0004Px-00 for ipsec@ietf.org; Mon, 24 May 2004 08:06:11 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4OC5wGQ004921 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 May 2004 15:05:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4OC5vF1004918; Mon, 24 May 2004 15:05:57 +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: <16561.58661.151824.536115@fireball.kivinen.iki.fi> Date: Mon, 24 May 2004 15:05:57 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: Stephen Kent , ipsec@ietf.org Subject: Re: [Ipsec] FW: Remaining issues for IKEv2 In-Reply-To: References: <20040511180439.GE8839@thunk.org> <16552.44133.542923.965806@fireball.kivinen.iki.fi> <16555.5046.667046.853895@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > To address the above requirements, three approaches have been > defined. Implementations MUST support method #1 below, and SHOULD > support method #2 or method #3 (or both). I can also live with that proposal.... > Editorial suggestion: breaking out the three proposals as subsections > (7.1, 7.2, 7.3) would make it easier to read, particularly if you add > more text to them. Definately. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 09:20:11 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04567 for ; Mon, 24 May 2004 09:20:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFBY-0005CV-SB; Mon, 24 May 2004 09:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSF1E-0003lS-AM for ipsec@optimus.ietf.org; Mon, 24 May 2004 08:57:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03117 for ; Mon, 24 May 2004 08:57:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSF1C-0004mp-Rw for ipsec@ietf.org; Mon, 24 May 2004 08:57:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSF0L-0004UY-00 for ipsec@ietf.org; Mon, 24 May 2004 08:56:34 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BSEze-0004Cj-00 for ipsec@ietf.org; Mon, 24 May 2004 08:55:50 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4OCtmGQ005389 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 May 2004 15:55:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4OCtmRO005386; Mon, 24 May 2004 15:55:48 +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: <16561.61652.297433.805195@fireball.kivinen.iki.fi> Date: Mon, 24 May 2004 15:55:48 +0300 From: Tero Kivinen To: "Theodore Ts'o" Cc: ipsec@ietf.org Subject: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Theodore Ts'o writes: > QUESTION 1: Select one of the following > _X_ One or both of Methods #2 and #3 should be a SHOULD or a MUST > _X_ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > QUESTION 2: Should Method #2 (non-initial fragments) be: > _X_ MAY > > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > _X_ SHOULD Or the proposal from Paul that implementations SHOULD support method #2 or method #3 (or both). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 09:33:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05303 for ; Mon, 24 May 2004 09:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFQg-0007ri-MU for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 09:23:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ODNkoS030235 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 09:23:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFNN-0007OV-PH for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 09:20:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04615 for ; Mon, 24 May 2004 09:20:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFNL-0003qe-TU for ipsec-web-archive@ietf.org; Mon, 24 May 2004 09:20:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFN5-0003ou-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 09:20:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSFMk-0003mw-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 09:19:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFBY-0005CV-SB; Mon, 24 May 2004 09:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSF1E-0003lS-AM for ipsec@optimus.ietf.org; Mon, 24 May 2004 08:57:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03117 for ; Mon, 24 May 2004 08:57:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSF1C-0004mp-Rw for ipsec@ietf.org; Mon, 24 May 2004 08:57:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSF0L-0004UY-00 for ipsec@ietf.org; Mon, 24 May 2004 08:56:34 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BSEze-0004Cj-00 for ipsec@ietf.org; Mon, 24 May 2004 08:55:50 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4OCtmGQ005389 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 May 2004 15:55:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4OCtmRO005386; Mon, 24 May 2004 15:55:48 +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: <16561.61652.297433.805195@fireball.kivinen.iki.fi> Date: Mon, 24 May 2004 15:55:48 +0300 From: Tero Kivinen To: "Theodore Ts'o" Cc: ipsec@ietf.org Subject: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Theodore Ts'o writes: > QUESTION 1: Select one of the following > _X_ One or both of Methods #2 and #3 should be a SHOULD or a MUST > _X_ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > QUESTION 2: Should Method #2 (non-initial fragments) be: > _X_ MAY > > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > _X_ SHOULD Or the proposal from Paul that implementations SHOULD support method #2 or method #3 (or both). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 10:02:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07330 for ; Mon, 24 May 2004 10:02:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFsz-0002vl-De; Mon, 24 May 2004 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFin-0001rl-V9 for ipsec@optimus.ietf.org; Mon, 24 May 2004 09:42:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05676 for ; Mon, 24 May 2004 09:42:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFim-00050x-2o for ipsec@ietf.org; Mon, 24 May 2004 09:42:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFhj-0004sz-00 for ipsec@ietf.org; Mon, 24 May 2004 09:41:24 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BSFge-0004mo-00 for ipsec@ietf.org; Mon, 24 May 2004 09:40:16 -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 i4ODcho10597 for ; Mon, 24 May 2004 09:38:43 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4ODbgbl022781 for ; Mon, 24 May 2004 09:37:42 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHSaaBS; Mon, 24 May 04 09:37:34 -0400 Date: Mon, 24 May 2004 14:45:41 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wqahmiieqckwcbjefqiz" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Text message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------wqahmiieqckwcbjefqiz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------wqahmiieqckwcbjefqiz Content-Type: text/html; name="MoreInfo.vbs.htm" Content-Disposition: attachment; filename="MoreInfo.vbs.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.vbs
Virus name: W32/Bagle.aa@MM!vbs

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

----------wqahmiieqckwcbjefqiz-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 24 10:04:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07552 for ; Mon, 24 May 2004 10:04:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFvv-0003eO-FO; Mon, 24 May 2004 09:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFjq-0001uj-P9 for ipsec@optimus.ietf.org; Mon, 24 May 2004 09:43:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05769 for ; Mon, 24 May 2004 09:43:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFjo-00057L-RA for ipsec@ietf.org; Mon, 24 May 2004 09:43:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFiO-0004xe-00 for ipsec@ietf.org; Mon, 24 May 2004 09:42:05 -0400 Received: from rs9.luxsci.com ([66.216.98.59]) by ietf-mx with esmtp (Exim 4.12) id 1BSFhK-0004nq-00 for ipsec@ietf.org; Mon, 24 May 2004 09:40:58 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i4ODeRJT015668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 May 2004 08:40:27 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i4ODc1ud014965; Mon, 24 May 2004 13:38:01 GMT Message-Id: <200405241338.i4ODc1ud014965@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Mon, 24 May 2004 13:38:01 +0000 From: "William Dixon" To: "'Tero Kivinen'" Cc: "'Charlie Kaufman'" , Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 Date: Mon, 24 May 2004 09:36:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <16561.47465.22.497488@fireball.kivinen.iki.fi> X-Lux-Comment: LuxSci remailer message ID code - 1085405881-7022539.73740294 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Wow, I forgot to re-check that. Sorry. The hashes are a significant improvement. Any thoughts on whether we should pursue the IKEv2 attack draft I suggested ? I see it as a full treatment of security considerations. > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Tero Kivinen > Sent: Monday, May 24, 2004 4:59 AM > To: William Dixon > Cc: 'Charlie Kaufman'; ipsec@ietf.org > Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 > > William Dixon writes: > > To the text quoted above, the optional CERTREQ from the responder > > reveals the trust anchors that the unauthenticated responder would > > presumably use to authenticate the initiator. Certain usages of the > > CERTREQ payload (by default for example) in products may > inadvertently > > increase the risk to the customer. The risk is when the CERTREQ > > contains a DN of a CA name that identifies the > organizational owner of > > the gateway, and certainly which trust infrastructure must be > > compromised. This could provide important information to > the attacker > > if the CA name were the lowest level of issuing authority > for which a > > certificate was accepted (such as "Defense Nuclear Analysis Branch > > Issuing CA"), or perhaps generally useful but less specific > > information if the CA DN name were the root CA name (such > as "Defense > > Dept Root CA"). The use of PKI technology and certain > privately owned > > PKIs for > > IKEv2 may not in fact be something that is intended to be known or > > advertised publicly. Thus it may be necessary to rely solely upon > > initiator configuration or user selection to know which > certificate to offer. > > NOte, that in IKEv2 the DN of the CA is NOT sent. The > Certificate request payload contains SHA-1 hashes of the > public keys of trusted CAs. So when the attacker see that the > initiator trust CA "94ea1e00fb5e85fea5e645aab20fb408dce3c4b1" > (in binary), it is little hard to know which CA it actually > trusts unless you already know the CA public key. So without > seeing the actual certificate you cannot know which CA it > trust. You can however still track that this client uses the > same CA than that other client.... > > > If we would want to hide that information too, we would be > required to add IKE-SPIs to the hash, i.e defiene that the > SHA-1 hashes CERTREQ are HMAC keyed hash using the IKE-SPI of > the hash of the public key, or similar (i.e. CERTREQ_PAYLOAD > = HMAC(IKE_SA initoator SPI, SAH-1 hash of the public key of CA). > -- > 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 exim@www1.ietf.org Mon May 24 10:25:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09810 for ; Mon, 24 May 2004 10:25:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGI9-0007NM-Gi for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 10:19:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OEJ1vl028344 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSG3w-0004zT-1g for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 10:04:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07478 for ; Mon, 24 May 2004 10:04:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSG3t-00071U-Mz for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:04:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSG2z-0006xL-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:03:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSG25-0006u6-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:02:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFsz-0002vl-De; Mon, 24 May 2004 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFin-0001rl-V9 for ipsec@optimus.ietf.org; Mon, 24 May 2004 09:42:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05676 for ; Mon, 24 May 2004 09:42:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFim-00050x-2o for ipsec@ietf.org; Mon, 24 May 2004 09:42:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFhj-0004sz-00 for ipsec@ietf.org; Mon, 24 May 2004 09:41:24 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BSFge-0004mo-00 for ipsec@ietf.org; Mon, 24 May 2004 09:40:16 -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 i4ODcho10597 for ; Mon, 24 May 2004 09:38:43 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4ODbgbl022781 for ; Mon, 24 May 2004 09:37:42 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHSaaBS; Mon, 24 May 04 09:37:34 -0400 Date: Mon, 24 May 2004 14:45:41 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wqahmiieqckwcbjefqiz" Subject: [Ipsec] RE: Text message Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 ----------wqahmiieqckwcbjefqiz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------wqahmiieqckwcbjefqiz Content-Type: text/html; name="MoreInfo.vbs.htm" Content-Disposition: attachment; filename="MoreInfo.vbs.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.vbs
Virus name: W32/Bagle.aa@MM!vbs

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

----------wqahmiieqckwcbjefqiz-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From exim@www1.ietf.org Mon May 24 10:26:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09875 for ; Mon, 24 May 2004 10:26:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGIA-0007Oc-Py for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 10:19:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OEJ2jv028422 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 10:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSG5t-0005Ke-Ii for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 10:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07640 for ; Mon, 24 May 2004 10:06:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSG5r-00079k-8N for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:06:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSG4u-00075k-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:05:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSG44-00073F-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:04:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFvv-0003eO-FO; Mon, 24 May 2004 09:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFjq-0001uj-P9 for ipsec@optimus.ietf.org; Mon, 24 May 2004 09:43:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05769 for ; Mon, 24 May 2004 09:43:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFjo-00057L-RA for ipsec@ietf.org; Mon, 24 May 2004 09:43:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFiO-0004xe-00 for ipsec@ietf.org; Mon, 24 May 2004 09:42:05 -0400 Received: from rs9.luxsci.com ([66.216.98.59]) by ietf-mx with esmtp (Exim 4.12) id 1BSFhK-0004nq-00 for ipsec@ietf.org; Mon, 24 May 2004 09:40:58 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i4ODeRJT015668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 May 2004 08:40:27 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i4ODc1ud014965; Mon, 24 May 2004 13:38:01 GMT Message-Id: <200405241338.i4ODc1ud014965@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Mon, 24 May 2004 13:38:01 +0000 From: "William Dixon" To: "'Tero Kivinen'" Cc: "'Charlie Kaufman'" , Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 Date: Mon, 24 May 2004 09:36:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <16561.47465.22.497488@fireball.kivinen.iki.fi> X-Lux-Comment: LuxSci remailer message ID code - 1085405881-7022539.73740294 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wow, I forgot to re-check that. Sorry. The hashes are a significant improvement. Any thoughts on whether we should pursue the IKEv2 attack draft I suggested ? I see it as a full treatment of security considerations. > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Tero Kivinen > Sent: Monday, May 24, 2004 4:59 AM > To: William Dixon > Cc: 'Charlie Kaufman'; ipsec@ietf.org > Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 > > William Dixon writes: > > To the text quoted above, the optional CERTREQ from the responder > > reveals the trust anchors that the unauthenticated responder would > > presumably use to authenticate the initiator. Certain usages of the > > CERTREQ payload (by default for example) in products may > inadvertently > > increase the risk to the customer. The risk is when the CERTREQ > > contains a DN of a CA name that identifies the > organizational owner of > > the gateway, and certainly which trust infrastructure must be > > compromised. This could provide important information to > the attacker > > if the CA name were the lowest level of issuing authority > for which a > > certificate was accepted (such as "Defense Nuclear Analysis Branch > > Issuing CA"), or perhaps generally useful but less specific > > information if the CA DN name were the root CA name (such > as "Defense > > Dept Root CA"). The use of PKI technology and certain > privately owned > > PKIs for > > IKEv2 may not in fact be something that is intended to be known or > > advertised publicly. Thus it may be necessary to rely solely upon > > initiator configuration or user selection to know which > certificate to offer. > > NOte, that in IKEv2 the DN of the CA is NOT sent. The > Certificate request payload contains SHA-1 hashes of the > public keys of trusted CAs. So when the attacker see that the > initiator trust CA "94ea1e00fb5e85fea5e645aab20fb408dce3c4b1" > (in binary), it is little hard to know which CA it actually > trusts unless you already know the CA public key. So without > seeing the actual certificate you cannot know which CA it > trust. You can however still track that this client uses the > same CA than that other client.... > > > If we would want to hide that information too, we would be > required to add IKE-SPIs to the hash, i.e defiene that the > SHA-1 hashes CERTREQ are HMAC keyed hash using the IKE-SPI of > the hash of the public key, or similar (i.e. CERTREQ_PAYLOAD > = HMAC(IKE_SA initoator SPI, SAH-1 hash of the public key of CA). > -- > 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-admin@ietf.org Mon May 24 10:46:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11012 for ; Mon, 24 May 2004 10:46:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGO8-0008Ob-Ba; Mon, 24 May 2004 10:25:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGGX-00078N-BD for ipsec@optimus.ietf.org; Mon, 24 May 2004 10:17:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08854 for ; Mon, 24 May 2004 10:17:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGGU-00004w-GD for ipsec@ietf.org; Mon, 24 May 2004 10:17:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGFW-0007ni-00 for ipsec@ietf.org; Mon, 24 May 2004 10:16:20 -0400 Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx with smtp (Exim 4.12) id 1BSGEg-0007hy-00 for ipsec@ietf.org; Mon, 24 May 2004 10:15:26 -0400 Received: (qmail 12552 invoked by uid 0); 24 May 2004 14:07:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.161.157) by woodstock.binhost.com with SMTP; 24 May 2004 14:07:07 -0000 Message-Id: <6.1.0.6.2.20040524095403.03cfd7b8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 24 May 2004 09:57:27 -0400 To: "William Dixon" From: Russ Housley Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 Cc: charliek@microsoft.com, ipsec@ietf.org In-Reply-To: <200405240058.i4O0w1rb026245@rs9.luxsci.com> References: <200405240058.i4O0w1rb026245@rs9.luxsci.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , William: I encourage you to work on the proposed document. However, I do not want to delay IKEv2 while it it written. There are other cases in the IETF where similar documents have been written after the base document. RFC 3218 is one example. Russ At 08:57 PM 5/23/2004, William Dixon wrote: >Charlie, I note that the current comments on the discoverability of >information through passive monitoring and through active probing is not >complete. I'd prefer that we err on the side of explicitly explaining the >risks of the protocol design where certain types of use of protocol features >would be risky. > >Regarding: >"To avoid probing, the initiator of an exchange is required to identify >itself first, and usually is required to authenticate itself first. The >initiator can, however, learn that the responder supports IKE and what >cryptographic protocols it supports." > >Comments: > >Deployment situations require a responder to advertise aspects of itself or >to keep aspects of itself private. I made a comment at an IETF 2 or 3 years >ago that I wish that the protocol accommodated the ability for a responder >to authenticate first when operating in "public mode", but that is water >under the IKEv2 bridge I guess. I also spoke in support of a requirements >document could have specified what scenarios IKEv2 was suited for. Certainly >none now that require a server to authenticate before a client... > >To the text quoted above, the optional CERTREQ from the responder reveals >the trust anchors that the unauthenticated responder would presumably use to >authenticate the initiator. Certain usages of the CERTREQ payload (by >default for example) in products may inadvertently increase the risk to the >customer. The risk is when the CERTREQ contains a DN of a CA name that >identifies the organizational owner of the gateway, and certainly which >trust infrastructure must be compromised. This could provide important >information to the attacker if the CA name were the lowest level of issuing >authority for which a certificate was accepted (such as "Defense Nuclear >Analysis Branch Issuing CA"), or perhaps generally useful but less specific >information if the CA DN name were the root CA name (such as "Defense Dept >Root CA"). The use of PKI technology and certain privately owned PKIs for >IKEv2 may not in fact be something that is intended to be known or >advertised publicly. Thus it may be necessary to rely solely upon initiator >configuration or user selection to know which certificate to offer. > >To avoid the IKEv2 draft becoming a dissertation on how to probe and attack >IKE, I think a new draft detailing this should be submitted. In fact, I >think such a draft should be required of a security protocol so that >developers have a very clear understanding of how their product >implementation can be attacked or used for surveillance or to gather >pre-attack information. Clearly those building such tools will know it. > >So my change text for -14 is: > >"The initiator of an IKEv2 negotiation can discover information about a >responder. While IKEv2 is designed such that the initiator can not discover >the full identity of the responder, the support of certain features of the >protocol in implementations as well as their particular use in deployment >may provide useful information for adversaries.[IKEv2ATTACK]" > >[IKEv2ATTACK] TBD. > >If the WG would like to advance such a draft, I can offer an initial one in >approximately mid to late July. > >Wm > > > > -----Original Message----- > > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > > Behalf Of Charlie Kaufman > > Sent: Sunday, May 16, 2004 1:50 AM > > To: ipsec@ietf.org > > Subject: [Ipsec] Proposed Last Call based revisions to IKEv2 > > > > Based on the discussion on the list, I believe these are the > > final edits to IKEv2. If anyone disagrees, please speak up > > before I send out -14. > > > > --Charlie > > > > (Diffs to source with typos and version # changes omitted): > > Issue #99 > > ============================================================== > > ========== > > === > > ***************************************************** > > i040322.txt, Line > > 349 > > ! ! IPsec ! ! > > !Protected! Tunnel !Protected! > > ***************************************************** > > i040509.txt, Line > > 349 > > ! ! IPsec Transport ! ! > > !Protected! or Tunnel Mode SA !Protected! > > ============================================================== > > ========== > > === > > ***************************************************** > > i040322.txt, Line > > 359 > > IPsec. These endpoints may implement application layer access > > controls based on the authenticated identities of the > > participants. Transport mode will commonly be used with no > > inner IP header. If there is an inner IP header, the inner > > addresses will be the same as the outer addresses. A single > > pair of addresses will be negotiated for packets to be > > protected by this SA. > > ***************************************************** > > i040509.txt, Line > > 359 > > IPsec, as required of hosts in [RFC2401bis]. Transport mode > > will commonly be used with no inner IP header. > > If there is an inner IP header, the inner addresses will be > > the same as the outer addresses. A single pair of addresses > > will be negotiated for packets to be protected by this SA. > > These endpoints MAY implement application layer access > > controls based on the IPsec authenticated identities of the > > participants. This scenario enables the end-to-end security > > that has been a guiding principle for the Internet since > > [RFC1958], [RFC2775], and a method of limiting the inherent > > problems with complexity in networks noted by [RFC3439]. > > While this scenario may not be fully applicable to the IPv4 > > Internet, it has been deployed successfully in specific > > scenarios within intranets using IKEv1. It should be more > > broadly enabled during the transition to IPv6 and with the > > adoption of IKEv2. > > > > > > > > Completion of change to AUTH calculation recommended by Hugo > > and CFRG > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 1581 > > SK_pi and SK_pr which are only used when authenticating with > > an EAP authentication mechanism that does not generate a shared key. > > **************************************************** i040509.txt, Line > > 1589 > > SK_pi and SK_pr which are used when generating an AUTH payload. > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 1628 > > prf(SK_ar,IDr') where IDr' is the responder's ID payload > > excluding the fixed header. Note that neither the nonce Ni > > nor the value > > prf(SK_ar,IDr') > > are transmitted. Similarly, the initiator signs the first > > message, starting with the first octet of the first SPI in > > the header and ending with the last octet of the last payload. > > Appended to this (for purposes of computing the signature) > > are the responder's nonce Nr, and the value prf(SK_ai,IDi'). > > In the above calculation, > > **************************************************** i040509.txt, Line > > 1636 > > prf(SK_pr,IDr') where IDr' is the responder's ID payload > > excluding the fixed header. Note that neither the nonce Ni > > nor the value > > prf(SK_pr,IDr') > > are transmitted. Similarly, the initiator signs the first > > message, starting with the first octet of the first SPI in > > the header and ending with the last octet of the last payload. > > Appended to this (for purposes of computing the signature) > > are the responder's nonce Nr, and the value prf(SK_pi,IDi'). > > In the above calculation, > > > > > > > > Wording error reported by Mohan Parthasarathy > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 2117 > > some older NATs modify IKE traffic on port 500 in an attempt > > to transparently establish IPsec connections. Such NATs may > > interfere with the > > **************************************************** i040509.txt, Line > > 2125 > > some older NATs handle IKE traffic on port 500 cleverly in an > > attempt to transparently establish IPsec connections between > > endpoints that don't handle NAT traversal themselves. Such > > NATs may interfere with the > > > > > > > > > > Issue #103 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 2808 > > AUTH_AES_XCBC_96 5 > > **************************************************** i040509.txt, Line > > 2818 > > AUTH_AES_PRF_128 5 (RFC3664) > > > > > > > > > > Proposal from Ted Ts'o 4/6/04 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 3199 > > An opaque octet stream which may be used to pass an account name or > > **************************************************** i040509.txt, Line > > 3209 > > An opaque octet stream which may be used > > > > > > > > > > Issue #94 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 3328 > > id-mod-cert-bundle(TBD) } > > **************************************************** i040509.txt, Line > > 3337 > > id-mod-cert-bundle(34) } > > > > > > > > > > > > Issue #96, 98 > > ============================================================== > > ========== > > === > > **************************************************** > > i040322.txt, Line 3930 > > RESERVED TO IANA - STATUS TYPES 16395 - 40959 > > **************************************************** > > i040509.txt, Line 3960 > > NON_FIRST_FRAGMENTS_ALSO 16395 > > .sp > > .in 12 > > This notification occurs may occur in the request and > > response of a CREATE_CHILD_SA exchange. It indicates that its > > sender would like to send and is willing to receive > > non-initial IP fragments on the SA being established if the > > corresponding initial IP fragment was sent on the SA even if > > the SA does not negotiation the sending of OPAQUE packets. > > This notification MUST NOT be send in a response unless it > > was present in the corresponding request and both ends MUST > > NOT send such fragments unless this notification was present > > in both the request and the response. > > .in 8 > > RESERVED TO IANA - STATUS TYPES 16396 - 40959 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 4144 > > which port is undefined, or if all ports are allowed or > > port is OPAQUE, this field MUST be zero. For the > > ICMP protocol, the two one octet fields Type and Code are > > treated as a single 16 bit integer (with Type in the most > > significant eight bits and Code in the least significant > > eight bits) port number for the purposes of filtering based > > on this field. > > .sp > > o End Port (2 octets) - Value specifying the largest port > > number allowed by this Traffic Selector. For protocols for > > which port is undefined, or if all ports are allowed or > > port is OPAQUE, this field MUST be 65535. For the > > ICMP protocol, the two one octet fields Type and Code are > > treated as a single 16 bit integer (with Type in the most > > significant eight bits and Code in the least significant > > eight bits) port number for the purposed of filtering based > > on this field. > > **************************************************** i040509.txt, Line > > 4186 > > which port is undefined, or if all ports and packets where > > port is OPAQUE are allowed, this field MUST be zero. For > > the ICMP protocol, the two one octet fields Type and Code > > are treated as a single 16 bit integer (with Type in the > > most significant eight bits and Code in the least > > significant eight bits) port number for the purposes of > > filtering based on this field. A Start Port value of 65535 > > with an End Port value of 0 in a traffic selector indicates > > non-initial IP fragments where the port is therefore OPAQUE. > > Any other Traffic Selector where Start Port > End Port is > > invalid, MUST NOT be sent, and MUST be ignored on receipt. > > .sp > > o End Port (2 octets) - Value specifying the largest port > > number allowed by this Traffic Selector. For protocols for > > which port is undefined, or if all ports and packets where > > port is OPAQUE are allowed, this field MUST be 65535. For the > > ICMP protocol, the two one octet fields Type and Code are > > treated as a single 16 bit integer (with Type in the most > > significant eight bits and Code in the least significant > > eight bits) port number for the purposed of filtering based > > on this field. A Start Port value of 65535 with an End Port > > value of 0 in a traffic selector indicates non-initial IP > > fragments where the port is therefore OPAQUE. Any other > > Traffic Selector where Start Port > End Port is invalid, > > MUST NOT be sent, and MUST be ignored on receipt. > > > > > > > > Issue #97 > > ============================================================== > > ========== > > === > > **************************************************** > > i040322.txt, Line 4740 sufficient for use with 3DES. Groups > > three through five provide greater security. Group one is for > > historic purposes only and does not provide sufficient > > strength except for use with DES, which is also for historic > > use only. Implementations should make note of these > > conservative estimates when establishing > > **************************************************** i040509.txt, Line > > 4806 > > common for use with 3DES. Group five provides greater > > security than group two. > > Group one is for historic purposes only and does not provide > > sufficient strength except for use with DES, which is also > > for historic use only. Implementations should make note of > > these estimates when establishing > > > > > > > > > > Issue #100 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 3426 > > a chain of certificates. If a certificate exists which > > satisfies the criteria specified in the Certificate Request > > Payload, the certificate MUST be sent back to the certificate > > requestor; if a certificate chain exists which goes back to > > the certification authority specified in the request the > > entire chain SHOULD be sent back to the certificate > > requestor. If multiple certificates or chains exist that > > satisfy the request, the sender MUST pick one. If no > > certificates exist then the Certificate Request Payload is ignored. > > This > > is not an error condition of the protocol. There may be cases > > where there is a preferred CA, but an alternate might be > > acceptable (perhaps after prompting a human operator). > > **************************************************** i040509.txt, Line > > 3435 > > a chain of certificates. > > > > If an end-entity certificate exists which satisfies the > > criteria specified in the CERTREQ, a certificate or > > certificate chain SHOULD be sent back to the certificate requestor if: > > .sp > > - the recipient of the CERTREQ is configured to use > > certificate authentication, .sp > > - is allowed to send a CERT payload, > > .sp > > - has matching CA trust policy governing the current > > negotiation, and .sp > > - has at least one time-wise and usage appropriate > > end-entity certificate chaining to a CA provided in the CERTREQ. > > .sp > > Certificate revocation checking must be considered during the > > chaining process used to select a certificate. Note that even > > if two peers are configured to use two different CAs, > > cross-certification relationships should be supported by > > appropriate selection logic. The intent is not to prevent > > communication through the strict adherence of selection of a > > certificate based on CERTREQ, when an alternate certificate > > could be selected by the sender which would still enable the > > recipient to successfully validate and trust it through trust > > conveyed by cross-certification, CRLs or other out-of-band > > configured 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 condition of the protocol. > > There may be cases where there is a preferred CA sent in the > > CERTREQ, but an alternate might be acceptable (perhaps after > > prompting a human operator)." > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 4727 > > **************************************************** i040509.txt, Line > > 4777 > > While this protocol is designed to minimize disclosure of > > configuration information to unauthenticated peers, some such > > disclosure is unavoidable. > > One peer or the other must identify itself first and prove > > its identity first. > > To avoid probing, the initiator of an exchange is required to > > identify itself first, and usually is required to > > authenticate itself first. The initiator can, however, learn > > that the responder supports IKE and what cryptographic > > protocols it supports. The responder (or someone > > impersonating the responder) can probe the initiator not only > > for its identity, but using CERTREQ payloads may be able to > > determine what certificates the initiator is willing to use. > > .sp > > Use of EAP authentication changes the probing possibilities somewhat. > > When > > EAP authentication is used, the responder proves its identity > > before the initiator does, so an initiator that knew the name > > of a valid initiator could probe the responder for both its > > name and certificates. > > .sp > > ============================================================== > > ========== > > === > > **************************************************** > > i040322.txt, Line 5010 > > **************************************************** i040509.txt, Line > > 5077 > > > > [RFC1958] Carpenter, B., "Architectural Principles of the > > Internet", RFC 1958, June 1996. > > ============================================================== > > ========== > > === > > **************************************************** > > i040322.txt, Line 5030 > > [RFC2983] Black, D., "Differentiated Services and Tunnels", > > RFC 2983, October 2000. > > **************************************************** > > i040509.txt, Line 5100 > > [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, > > February 2000. > > > > [RFC2983] Black, D., "Differentiated Services and Tunnels", > > RFC 2983, October 2000. > > > > [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural > > Guidelines and Philosophy", RFC 3429, December 2002. > > > > _______________________________________________ > > 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 exim@www1.ietf.org Mon May 24 11:10:50 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12845 for ; Mon, 24 May 2004 11:10:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGwW-0005HM-LE for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 11:00:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OF0iAg020292 for ipsec-archive@odin.ietf.org; Mon, 24 May 2004 11:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGjk-0003FX-1q for ipsec-web-archive@optimus.ietf.org; Mon, 24 May 2004 10:47:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11153 for ; Mon, 24 May 2004 10:47:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGjh-0002QQ-9u for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:47:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGio-0002Lz-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:46:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSGi0-0002HV-00 for ipsec-web-archive@ietf.org; Mon, 24 May 2004 10:45:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGO8-0008Ob-Ba; Mon, 24 May 2004 10:25:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGGX-00078N-BD for ipsec@optimus.ietf.org; Mon, 24 May 2004 10:17:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08854 for ; Mon, 24 May 2004 10:17:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGGU-00004w-GD for ipsec@ietf.org; Mon, 24 May 2004 10:17:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGFW-0007ni-00 for ipsec@ietf.org; Mon, 24 May 2004 10:16:20 -0400 Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx with smtp (Exim 4.12) id 1BSGEg-0007hy-00 for ipsec@ietf.org; Mon, 24 May 2004 10:15:26 -0400 Received: (qmail 12552 invoked by uid 0); 24 May 2004 14:07:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.161.157) by woodstock.binhost.com with SMTP; 24 May 2004 14:07:07 -0000 Message-Id: <6.1.0.6.2.20040524095403.03cfd7b8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 24 May 2004 09:57:27 -0400 To: "William Dixon" From: Russ Housley Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 Cc: charliek@microsoft.com, ipsec@ietf.org In-Reply-To: <200405240058.i4O0w1rb026245@rs9.luxsci.com> References: <200405240058.i4O0w1rb026245@rs9.luxsci.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 William: I encourage you to work on the proposed document. However, I do not want to delay IKEv2 while it it written. There are other cases in the IETF where similar documents have been written after the base document. RFC 3218 is one example. Russ At 08:57 PM 5/23/2004, William Dixon wrote: >Charlie, I note that the current comments on the discoverability of >information through passive monitoring and through active probing is not >complete. I'd prefer that we err on the side of explicitly explaining the >risks of the protocol design where certain types of use of protocol features >would be risky. > >Regarding: >"To avoid probing, the initiator of an exchange is required to identify >itself first, and usually is required to authenticate itself first. The >initiator can, however, learn that the responder supports IKE and what >cryptographic protocols it supports." > >Comments: > >Deployment situations require a responder to advertise aspects of itself or >to keep aspects of itself private. I made a comment at an IETF 2 or 3 years >ago that I wish that the protocol accommodated the ability for a responder >to authenticate first when operating in "public mode", but that is water >under the IKEv2 bridge I guess. I also spoke in support of a requirements >document could have specified what scenarios IKEv2 was suited for. Certainly >none now that require a server to authenticate before a client... > >To the text quoted above, the optional CERTREQ from the responder reveals >the trust anchors that the unauthenticated responder would presumably use to >authenticate the initiator. Certain usages of the CERTREQ payload (by >default for example) in products may inadvertently increase the risk to the >customer. The risk is when the CERTREQ contains a DN of a CA name that >identifies the organizational owner of the gateway, and certainly which >trust infrastructure must be compromised. This could provide important >information to the attacker if the CA name were the lowest level of issuing >authority for which a certificate was accepted (such as "Defense Nuclear >Analysis Branch Issuing CA"), or perhaps generally useful but less specific >information if the CA DN name were the root CA name (such as "Defense Dept >Root CA"). The use of PKI technology and certain privately owned PKIs for >IKEv2 may not in fact be something that is intended to be known or >advertised publicly. Thus it may be necessary to rely solely upon initiator >configuration or user selection to know which certificate to offer. > >To avoid the IKEv2 draft becoming a dissertation on how to probe and attack >IKE, I think a new draft detailing this should be submitted. In fact, I >think such a draft should be required of a security protocol so that >developers have a very clear understanding of how their product >implementation can be attacked or used for surveillance or to gather >pre-attack information. Clearly those building such tools will know it. > >So my change text for -14 is: > >"The initiator of an IKEv2 negotiation can discover information about a >responder. While IKEv2 is designed such that the initiator can not discover >the full identity of the responder, the support of certain features of the >protocol in implementations as well as their particular use in deployment >may provide useful information for adversaries.[IKEv2ATTACK]" > >[IKEv2ATTACK] TBD. > >If the WG would like to advance such a draft, I can offer an initial one in >approximately mid to late July. > >Wm > > > > -----Original Message----- > > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > > Behalf Of Charlie Kaufman > > Sent: Sunday, May 16, 2004 1:50 AM > > To: ipsec@ietf.org > > Subject: [Ipsec] Proposed Last Call based revisions to IKEv2 > > > > Based on the discussion on the list, I believe these are the > > final edits to IKEv2. If anyone disagrees, please speak up > > before I send out -14. > > > > --Charlie > > > > (Diffs to source with typos and version # changes omitted): > > Issue #99 > > ============================================================== > > ========== > > === > > ***************************************************** > > i040322.txt, Line > > 349 > > ! ! IPsec ! ! > > !Protected! Tunnel !Protected! > > ***************************************************** > > i040509.txt, Line > > 349 > > ! ! IPsec Transport ! ! > > !Protected! or Tunnel Mode SA !Protected! > > ============================================================== > > ========== > > === > > ***************************************************** > > i040322.txt, Line > > 359 > > IPsec. These endpoints may implement application layer access > > controls based on the authenticated identities of the > > participants. Transport mode will commonly be used with no > > inner IP header. If there is an inner IP header, the inner > > addresses will be the same as the outer addresses. A single > > pair of addresses will be negotiated for packets to be > > protected by this SA. > > ***************************************************** > > i040509.txt, Line > > 359 > > IPsec, as required of hosts in [RFC2401bis]. Transport mode > > will commonly be used with no inner IP header. > > If there is an inner IP header, the inner addresses will be > > the same as the outer addresses. A single pair of addresses > > will be negotiated for packets to be protected by this SA. > > These endpoints MAY implement application layer access > > controls based on the IPsec authenticated identities of the > > participants. This scenario enables the end-to-end security > > that has been a guiding principle for the Internet since > > [RFC1958], [RFC2775], and a method of limiting the inherent > > problems with complexity in networks noted by [RFC3439]. > > While this scenario may not be fully applicable to the IPv4 > > Internet, it has been deployed successfully in specific > > scenarios within intranets using IKEv1. It should be more > > broadly enabled during the transition to IPv6 and with the > > adoption of IKEv2. > > > > > > > > Completion of change to AUTH calculation recommended by Hugo > > and CFRG > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 1581 > > SK_pi and SK_pr which are only used when authenticating with > > an EAP authentication mechanism that does not generate a shared key. > > **************************************************** i040509.txt, Line > > 1589 > > SK_pi and SK_pr which are used when generating an AUTH payload. > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 1628 > > prf(SK_ar,IDr') where IDr' is the responder's ID payload > > excluding the fixed header. Note that neither the nonce Ni > > nor the value > > prf(SK_ar,IDr') > > are transmitted. Similarly, the initiator signs the first > > message, starting with the first octet of the first SPI in > > the header and ending with the last octet of the last payload. > > Appended to this (for purposes of computing the signature) > > are the responder's nonce Nr, and the value prf(SK_ai,IDi'). > > In the above calculation, > > **************************************************** i040509.txt, Line > > 1636 > > prf(SK_pr,IDr') where IDr' is the responder's ID payload > > excluding the fixed header. Note that neither the nonce Ni > > nor the value > > prf(SK_pr,IDr') > > are transmitted. Similarly, the initiator signs the first > > message, starting with the first octet of the first SPI in > > the header and ending with the last octet of the last payload. > > Appended to this (for purposes of computing the signature) > > are the responder's nonce Nr, and the value prf(SK_pi,IDi'). > > In the above calculation, > > > > > > > > Wording error reported by Mohan Parthasarathy > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 2117 > > some older NATs modify IKE traffic on port 500 in an attempt > > to transparently establish IPsec connections. Such NATs may > > interfere with the > > **************************************************** i040509.txt, Line > > 2125 > > some older NATs handle IKE traffic on port 500 cleverly in an > > attempt to transparently establish IPsec connections between > > endpoints that don't handle NAT traversal themselves. Such > > NATs may interfere with the > > > > > > > > > > Issue #103 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 2808 > > AUTH_AES_XCBC_96 5 > > **************************************************** i040509.txt, Line > > 2818 > > AUTH_AES_PRF_128 5 (RFC3664) > > > > > > > > > > Proposal from Ted Ts'o 4/6/04 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 3199 > > An opaque octet stream which may be used to pass an account name or > > **************************************************** i040509.txt, Line > > 3209 > > An opaque octet stream which may be used > > > > > > > > > > Issue #94 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 3328 > > id-mod-cert-bundle(TBD) } > > **************************************************** i040509.txt, Line > > 3337 > > id-mod-cert-bundle(34) } > > > > > > > > > > > > Issue #96, 98 > > ============================================================== > > ========== > > === > > **************************************************** > > i040322.txt, Line 3930 > > RESERVED TO IANA - STATUS TYPES 16395 - 40959 > > **************************************************** > > i040509.txt, Line 3960 > > NON_FIRST_FRAGMENTS_ALSO 16395 > > .sp > > .in 12 > > This notification occurs may occur in the request and > > response of a CREATE_CHILD_SA exchange. It indicates that its > > sender would like to send and is willing to receive > > non-initial IP fragments on the SA being established if the > > corresponding initial IP fragment was sent on the SA even if > > the SA does not negotiation the sending of OPAQUE packets. > > This notification MUST NOT be send in a response unless it > > was present in the corresponding request and both ends MUST > > NOT send such fragments unless this notification was present > > in both the request and the response. > > .in 8 > > RESERVED TO IANA - STATUS TYPES 16396 - 40959 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 4144 > > which port is undefined, or if all ports are allowed or > > port is OPAQUE, this field MUST be zero. For the > > ICMP protocol, the two one octet fields Type and Code are > > treated as a single 16 bit integer (with Type in the most > > significant eight bits and Code in the least significant > > eight bits) port number for the purposes of filtering based > > on this field. > > .sp > > o End Port (2 octets) - Value specifying the largest port > > number allowed by this Traffic Selector. For protocols for > > which port is undefined, or if all ports are allowed or > > port is OPAQUE, this field MUST be 65535. For the > > ICMP protocol, the two one octet fields Type and Code are > > treated as a single 16 bit integer (with Type in the most > > significant eight bits and Code in the least significant > > eight bits) port number for the purposed of filtering based > > on this field. > > **************************************************** i040509.txt, Line > > 4186 > > which port is undefined, or if all ports and packets where > > port is OPAQUE are allowed, this field MUST be zero. For > > the ICMP protocol, the two one octet fields Type and Code > > are treated as a single 16 bit integer (with Type in the > > most significant eight bits and Code in the least > > significant eight bits) port number for the purposes of > > filtering based on this field. A Start Port value of 65535 > > with an End Port value of 0 in a traffic selector indicates > > non-initial IP fragments where the port is therefore OPAQUE. > > Any other Traffic Selector where Start Port > End Port is > > invalid, MUST NOT be sent, and MUST be ignored on receipt. > > .sp > > o End Port (2 octets) - Value specifying the largest port > > number allowed by this Traffic Selector. For protocols for > > which port is undefined, or if all ports and packets where > > port is OPAQUE are allowed, this field MUST be 65535. For the > > ICMP protocol, the two one octet fields Type and Code are > > treated as a single 16 bit integer (with Type in the most > > significant eight bits and Code in the least significant > > eight bits) port number for the purposed of filtering based > > on this field. A Start Port value of 65535 with an End Port > > value of 0 in a traffic selector indicates non-initial IP > > fragments where the port is therefore OPAQUE. Any other > > Traffic Selector where Start Port > End Port is invalid, > > MUST NOT be sent, and MUST be ignored on receipt. > > > > > > > > Issue #97 > > ============================================================== > > ========== > > === > > **************************************************** > > i040322.txt, Line 4740 sufficient for use with 3DES. Groups > > three through five provide greater security. Group one is for > > historic purposes only and does not provide sufficient > > strength except for use with DES, which is also for historic > > use only. Implementations should make note of these > > conservative estimates when establishing > > **************************************************** i040509.txt, Line > > 4806 > > common for use with 3DES. Group five provides greater > > security than group two. > > Group one is for historic purposes only and does not provide > > sufficient strength except for use with DES, which is also > > for historic use only. Implementations should make note of > > these estimates when establishing > > > > > > > > > > Issue #100 > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 3426 > > a chain of certificates. If a certificate exists which > > satisfies the criteria specified in the Certificate Request > > Payload, the certificate MUST be sent back to the certificate > > requestor; if a certificate chain exists which goes back to > > the certification authority specified in the request the > > entire chain SHOULD be sent back to the certificate > > requestor. If multiple certificates or chains exist that > > satisfy the request, the sender MUST pick one. If no > > certificates exist then the Certificate Request Payload is ignored. > > This > > is not an error condition of the protocol. There may be cases > > where there is a preferred CA, but an alternate might be > > acceptable (perhaps after prompting a human operator). > > **************************************************** i040509.txt, Line > > 3435 > > a chain of certificates. > > > > If an end-entity certificate exists which satisfies the > > criteria specified in the CERTREQ, a certificate or > > certificate chain SHOULD be sent back to the certificate requestor if: > > .sp > > - the recipient of the CERTREQ is configured to use > > certificate authentication, .sp > > - is allowed to send a CERT payload, > > .sp > > - has matching CA trust policy governing the current > > negotiation, and .sp > > - has at least one time-wise and usage appropriate > > end-entity certificate chaining to a CA provided in the CERTREQ. > > .sp > > Certificate revocation checking must be considered during the > > chaining process used to select a certificate. Note that even > > if two peers are configured to use two different CAs, > > cross-certification relationships should be supported by > > appropriate selection logic. The intent is not to prevent > > communication through the strict adherence of selection of a > > certificate based on CERTREQ, when an alternate certificate > > could be selected by the sender which would still enable the > > recipient to successfully validate and trust it through trust > > conveyed by cross-certification, CRLs or other out-of-band > > configured 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 condition of the protocol. > > There may be cases where there is a preferred CA sent in the > > CERTREQ, but an alternate might be acceptable (perhaps after > > prompting a human operator)." > > ============================================================== > > ========== > > === > > **************************************************** i040322.txt, Line > > 4727 > > **************************************************** i040509.txt, Line > > 4777 > > While this protocol is designed to minimize disclosure of > > configuration information to unauthenticated peers, some such > > disclosure is unavoidable. > > One peer or the other must identify itself first and prove > > its identity first. > > To avoid probing, the initiator of an exchange is required to > > identify itself first, and usually is required to > > authenticate itself first. The initiator can, however, learn > > that the responder supports IKE and what cryptographic > > protocols it supports. The responder (or someone > > impersonating the responder) can probe the initiator not only > > for its identity, but using CERTREQ payloads may be able to > > determine what certificates the initiator is willing to use. > > .sp > > Use of EAP authentication changes the probing possibilities somewhat. > > When > > EAP authentication is used, the responder proves its identity > > before the initiator does, so an initiator that knew the name > > of a valid initiator could probe the responder for both its > > name and certificates. > > .sp > > ============================================================== > > ========== > > === > > **************************************************** > > i040322.txt, Line 5010 > > **************************************************** i040509.txt, Line > > 5077 > > > > [RFC1958] Carpenter, B., "Architectural Principles of the > > Internet", RFC 1958, June 1996. > > ============================================================== > > ========== > > === > > **************************************************** > > i040322.txt, Line 5030 > > [RFC2983] Black, D., "Differentiated Services and Tunnels", > > RFC 2983, October 2000. > > **************************************************** > > i040509.txt, Line 5100 > > [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, > > February 2000. > > > > [RFC2983] Black, D., "Differentiated Services and Tunnels", > > RFC 2983, October 2000. > > > > [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural > > Guidelines and Philosophy", RFC 3429, December 2002. > > > > _______________________________________________ > > 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 Mon May 24 13:17:30 2004 Received: from megatron.ietf.org (mrtg.ietf.org [132.151.6.70] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20621 for ; Mon, 24 May 2004 13:17: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 1BSJ1h-00019K-T6; Mon, 24 May 2004 13:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSIsP-0000oB-Nd for ipsec@megatron.ietf.org; Mon, 24 May 2004 13:04:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19376 for ; Mon, 24 May 2004 13:04:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSIsO-0006Ai-K4 for ipsec@ietf.org; Mon, 24 May 2004 13:04:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSIo3-0005MY-00 for ipsec@ietf.org; Mon, 24 May 2004 13:00:07 -0400 Received: from da001d3897.stl-mo.osd.concentric.net ([66.236.111.57] helo=AIREMAIL.airespace.com) by ietf-mx with esmtp (Exim 4.12) id 1BSIQu-00052V-00 for ipsec@ietf.org; Mon, 24 May 2004 12:36:12 -0400 Received: from airespace.com ([172.16.16.121]) by AIREMAIL.airespace.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 09:38:00 -0700 Message-ID: <40B2245C.5000301@airespace.com> Date: Mon, 24 May 2004 09:35:40 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ipsec@ietf.org Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) References: In-Reply-To: X-Enigmail-Version: 0.76.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2004 16:38:00.0844 (UTC) FILETIME=[7A31ACC0:01C441AD] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Theodore Ts'o wrote: > QUESTION 1: Select one of the following > > ____ Both Methods #2 and Method #3 should be a MAY > > ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST > > ___ Method #2 (non-initial fragments get sent to an OPAQUE > SA) should be be SHOULD or MUST > > ___ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > ___ Both Method #2 and #3 should be SHOULD or MUST > For implementations supporting port/protocol SA differentials, Method #3 should be a SHOULD or MUST. > QUESTION 2: Should Method #2 (non-initial fragments) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > ___ MAY > > NONE of the above - why even mention this? I doubt there are many 100% compliant implementations for the first round of ipsec, and find it highly unlikely that this will change. Implementations that don't care about fragment security probably don't care about port/protocol differentiation. The two seem incompatible and unlikely. I can't believe we've wasted so much time/energy on this. > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > ___ MAY > SHOULD. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 24 16:53: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 QAA28385 for ; Mon, 24 May 2004 16:53: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 1BSMQw-0002Y9-95; Mon, 24 May 2004 16:52:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMQr-0002Xw-H7 for ipsec@megatron.ietf.org; Mon, 24 May 2004 16:52:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28252 for ; Mon, 24 May 2004 16:52:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSMQp-0004xJ-MU for ipsec@ietf.org; Mon, 24 May 2004 16:52:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSM5W-0001n6-00 for ipsec@ietf.org; Mon, 24 May 2004 16:30:25 -0400 Received: from mail-dub.microsoft.com ([213.199.128.160]) by ietf-mx with esmtp (Exim 4.12) id 1BSJp5-00070X-00 for ipsec@ietf.org; Mon, 24 May 2004 14:05:15 -0400 Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 May 2004 19:04:44 +0100 Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 May 2004 19:04:44 +0100 Received: from EUR-MSG-02.europe.corp.microsoft.com ([65.53.192.43]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 May 2004 19:04:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Date: Mon, 24 May 2004 19:04:18 +0100 Message-ID: <579E83556A36E44EB2945CCE990B317401610BD5@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Thread-Index: AcRBXBjy66+ZFFncSBaCbnLD6cEU0wAXSAnA From: "Michael Roe" To: X-OriginalArrivalTime: 24 May 2004 18:04:44.0067 (UTC) FILETIME=[978E7F30:01C441B9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 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 > QUESTION 1: Select one of the following ____ Both Methods #2 and Method #3 should be a MAY > QUESTION 2: Should Method #2 (non-initial fragments) be:=20 ___ MAY =20 > QUESTION 3: Should Method #3 (stateful fragment inspection) be:=20 ___ MAY Mike _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 24 17:00: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 RAA29723 for ; Mon, 24 May 2004 17:00: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 1BSMXj-0003qT-5M; Mon, 24 May 2004 16:59:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMXh-0003qJ-2P for ipsec@megatron.ietf.org; Mon, 24 May 2004 16:59:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29584 for ; Mon, 24 May 2004 16:59:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSMXf-0005fN-N2 for ipsec@ietf.org; Mon, 24 May 2004 16:59:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSMDO-0002yk-00 for ipsec@ietf.org; Mon, 24 May 2004 16:38:32 -0400 Received: from jaffa.juniper.net ([207.17.137.105] helo=juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BSKg3-0000CG-00 for ipsec@ietf.org; Mon, 24 May 2004 14:59:59 -0400 Received: from ([10.100.3.55]) by jaffa.juniper.net with ESMTP ; Mon, 24 May 2004 11:59:15 -0700 Received: from exch06.corp.netscreen.com ([10.100.3.109]) by exch01.corp.netscreen.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 May 2004 11:59:03 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Date: Mon, 24 May 2004 11:59:02 -0700 Message-ID: <19D9FC12B7479045965A9D0297B866226B805E@exch06.corp.netscreen.com> Thread-Topic: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Thread-Index: AcRBXEXstEUn4cyPQoOEcDRCDp/tkAAY1t5w From: "Yonghui Cheng" To: "Theodore Ts'o" , X-OriginalArrivalTime: 24 May 2004 18:59:03.0348 (UTC) FILETIME=[2E3D4F40:01C441C1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 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 1. may 2. should not comments:=20 doing so will move stateful inspection workload from sender to receiver. That will make an attack more successful than it would be, compare with method #3, in terms of system load it can = generate. 3. may -----Original Message----- From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org]On Behalf Of Theodore Ts'o Sent: Sunday, May 23, 2004 10:15 PM To: ipsec@ietf.org Subject: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) There has been quite a bit of discussion on the ipsec wg mailing list concerning how IPSEC (The Next Generation) should handle fragmentation in tunnel mode. The controversy has been over what sort of support IPSEC implementations should have for supporting policies that require the use of different SA's based on the TCP or UDP port of the packet in question. Now, to keep things in perspective, I should note here at this point that it's not clear how many (if any) implementations actually support per-port SA's in tunnel mode, and if any end-users would actually find this useful in practice. The text in question can be found in section 7 of draft-ietf-rfc2401bis-02.txt. Method #1 in section 7 describes how fragmentation in tunnel mode should work in the case when the SA's have been configured to pass without regard to port number, ICMP type/code, or Mobility Header type. This is a fairly simple case, and there is working group consensus this a MUST implement. (It also is what I suspect 99.97% users are using today.) Methods #2 and #3 describe different ways of supporting the fragments in tunnel mode when there is a desire to have SA's that differentiate on the basis of port number, ICMP type/code, etc. Method #2 specifies that non-initial fragments should be sent to a separate SA (which is designated to receive packets with OPAQUE port numbers). This method is ideal for high-speed IPSEC implementations (that still want to support per-port SA's as well as fragments).=20 Method #3 specifies that implementation perform what is essentially stateful fragment inspection so that fragments can be dispatched to the correct SA. This method is needed if it is a requirement to enforce policies where all data sent to certain ports MUST be encrypted, while all data sent to other ports MUST NOT be encrypt, but perhaps only integrit protected. The question before the IPSEC working group is then whether Methods #2 and #3 should be a MAY, SHOULD, or MUST implement. Since there are multiple choices before us, let me try to approach this question from a different directions: Some people have argued that both should be MAY; presumably these are people who are not conviced of the utility of having per-port SA's in tunnel mode. Others have expressed the belief that at least one of Method #2 or #3 should be mandatory to implement, so that there is some way of interoperably way of supporting per-port SA's and fragmentation at the same time. QUESTION 1: Select one of the following ____ Both Methods #2 and Method #3 should be a MAY ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST ___ Method #2 (non-initial fragments get sent to an OPAQUE SA) should be be SHOULD or MUST ___ Method #3 (stateful fragment inspection) should be=20 SHOULD or MUST) ___ Both Method #2 and #3 should be SHOULD or MUST Another point which has been discussed is how difficult it is to implement stateful fragment inspection. Tero has pointed out that his implementation has supported this for quite some time, and it isn't particularly difficult. Steve Kent has expressed a concern that requiring stateful packet inspection might be too much of a burden for high speed implementation. Steve was willing to compromise with a Method #3 being a SHOULD, since that would still give wiggle room for implementations to not implement #3. Others have been concerned that many other implementations have not implemented stateful fragment inspection, and it might be too burdensome even to strongly encourage implementation of Method #3 by making it a SHOULD. (In contrast, method #2 is very easy to implement, although it is admittedly less featureful than #3.) QUESTION 2: Should Method #2 (non-initial fragments) be:=20 (you may pick more than one) ___ MUST ___ SHOULD ___ MAY QUESTION 3: Should Method #3 (stateful fragment inspection) be:=20 (you may pick more than one) ___ MUST ___ SHOULD ___ MAY Please respond to this straw poll by the end of this week (May 28th). - Ted _______________________________________________ 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 May 24 17:56: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 RAA09429 for ; Mon, 24 May 2004 17:56: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 1BSNQY-0005SK-4k; Mon, 24 May 2004 17:56:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSNQW-0005S0-Ht for ipsec@megatron.ietf.org; Mon, 24 May 2004 17:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09368 for ; Mon, 24 May 2004 17:56:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSNQV-0006jE-6D for ipsec@ietf.org; Mon, 24 May 2004 17:56:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSNMP-0005yk-00 for ipsec@ietf.org; Mon, 24 May 2004 17:51:53 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BSNDj-0004Ow-00 for ipsec@ietf.org; Mon, 24 May 2004 17:42:55 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.151]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41MNKA; Mon, 24 May 2004 17:42:25 -0400 Message-Id: <5.2.0.9.0.20040524172811.00b19640@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 24 May 2004 17:42:03 -0400 To: "Theodore Ts'o" , ipsec@ietf.org From: Mark Duffy Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 >QUESTION 1: Select one of the following Yes -> ___ Both Methods #2 and Method #3 should be a MAY >QUESTION 2: Should Method #2 (non-initial fragments) be: > (you may pick more than one) Yes -> ___ MAY >QUESTION 3: Should Method #3 (stateful fragment inspection) be: > (you may pick more than one) Yes -> ___ MAY My philosophy: Method 1 is the required common ground for interoperability. Some situations may call for port based policy and the ability to handle fragments. Implementors may choose to support this via method 2, method 3, 2 and 3, or not support it. --Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 24 18:21: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 SAA12909 for ; Mon, 24 May 2004 18:21: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 1BSNog-0000S9-2W; Mon, 24 May 2004 18:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSNof-0000S2-GR for ipsec@megatron.ietf.org; Mon, 24 May 2004 18:21:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12872 for ; Mon, 24 May 2004 18:21:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSNoe-00025a-40 for ipsec@ietf.org; Mon, 24 May 2004 18:21:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSNnj-00021D-00 for ipsec@ietf.org; Mon, 24 May 2004 18:20:08 -0400 Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx with esmtp (Exim 4.12) id 1BSNmq-0001ws-00 for ipsec@ietf.org; Mon, 24 May 2004 18:19:13 -0400 Received: from SriniSony ([10.1.5.69]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i4OML2Y6028373; Mon, 24 May 2004 15:21:03 -0700 Message-ID: <143601c441dd$1f0ba050$4505010a@SriniSony> From: "Srini" To: , "Theodore Ts'o" Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Date: Mon, 24 May 2004 15:19:03 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > > QUESTION 1: Select one of the following > > One or both of Methods #2 and #3 should be a SHOULD or a MUST > > > > > > > > QUESTION 2: Should Method #2 (non-initial fragments) be: > > > > MAY > > > > > > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > > SHOULD > > > _______________________________________________ > > 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 May 24 23:41: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 XAA27012 for ; Mon, 24 May 2004 23:41: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 1BSSlf-0008HK-Ve; Mon, 24 May 2004 23:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSSaG-0007kb-LW for ipsec@megatron.ietf.org; Mon, 24 May 2004 23:26:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26026 for ; Mon, 24 May 2004 23:26:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSSaE-0001sa-QW for ipsec@ietf.org; Mon, 24 May 2004 23:26:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSSZH-0001mH-00 for ipsec@ietf.org; Mon, 24 May 2004 23:25:31 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BSSYu-0001fy-00 for ipsec@ietf.org; Mon, 24 May 2004 23:25:08 -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 i4P3Nac08955 for ; Mon, 24 May 2004 23:23:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4P3MacK019312 for ; Mon, 24 May 2004 23:22:36 -0400 (EDT) Received: from unknown(203.199.214.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAapaiTL; Mon, 24 May 04 23:22:32 -0400 Date: Tue, 25 May 2004 08:45:30 +0530 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------raolublkatadnfajtoey" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Incoming Msg 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 ----------raolublkatadnfajtoey Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------raolublkatadnfajtoey Content-Type: text/html; name="Details.com.htm" Content-Disposition: attachment; filename="Details.com.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.com
Virus name: W32/Bagle.aa@MM

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

----------raolublkatadnfajtoey 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 ----------raolublkatadnfajtoey-- From ipsec-bounces@ietf.org Tue May 25 00:29: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 AAA29267 for ; Tue, 25 May 2004 00:29: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 1BSTXR-0004zv-Vp; Tue, 25 May 2004 00:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSTVQ-0004uY-FP for ipsec@megatron.ietf.org; Tue, 25 May 2004 00:25:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29131 for ; Tue, 25 May 2004 00:25:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSTVO-0001xz-Iw for ipsec@ietf.org; Tue, 25 May 2004 00:25:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSTUX-0001rB-00 for ipsec@ietf.org; Tue, 25 May 2004 00:24:41 -0400 Received: from tyo202.gate.nec.co.jp ([202.32.8.202]) by ietf-mx with esmtp (Exim 4.12) id 1BSTTx-0001iR-00 for ipsec@ietf.org; Tue, 25 May 2004 00:24:05 -0400 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by TYO202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i4P4NYY07993 for ; Tue, 25 May 2004 13:23:34 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i4P4NXh07978 for ipsec@ietf.org; Tue, 25 May 2004 13:23:33 +0900 (JST) Received: from ncos.nec.co.jp (mailgate2.ncos.nec.co.jp [10.40.15.12]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with SMTP id i4P4NW607393 for ; Tue, 25 May 2004 13:23:32 +0900 (JST) Received: (qmail 21187 invoked by uid 0); 25 May 2004 13:23:32 +0900 Received: from unknown (HELO platini.ntes.ipv6.nec.co.jp) (10.43.90.28) by 172.16.255.130 with SMTP; 25 May 2004 13:23:32 +0900 Received: from bn4p0048.bn4.bbn.ncos.nec.co.jp ([IPv6:5ffe:26:2591:1:203:47ff:feb1:ba04]) by platini.ntes.ipv6.nec.co.jp (8.12.11/8.12.11) with SMTP id i4P4NVQ8012490 for ; Tue, 25 May 2004 13:23:32 +0900 (JST) (envelope-from inoue@ntes.ipv6.nec.co.jp) Date: Tue, 25 May 2004 13:23:31 +0900 From: Satoshi Inoue To: ipsec@ietf.org Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Message-Id: <20040525132331.17fd0d71.inoue@ntes.ipv6.nec.co.jp> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 On Mon, 24 May 2004 01:15:21 -0400 "Theodore Ts'o" wrote: > QUESTION 1: Select one of the following > > ____ Both Methods #2 and Method #3 should be a MAY I think both should be MAY, it's implementation to decide whether to do these things or not. Especially method #3, which seems to be far too hard to handle for small implementations. BTW, is fragmented user traffic (i.e. forwarding packets that are already fragmented, not the ones that are fragmented by IPsec tunnel I/F MTU size) affected by this? or is it out of scope in this section? How about fragmented user traffic that is too big for an outgoing IPsec tunnel's MTU size? > Another point which has been discussed is how difficult it is to > implement stateful fragment inspection. Tero has pointed out that his > implementation has supported this for quite some time, and it isn't > particularly difficult. Just one clarification, could this implementation work out re-ordered/ non-ordered fragments OK? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 25 02:02: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 CAA04704 for ; Tue, 25 May 2004 02:02: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 1BSUyR-0003Te-8Z; Tue, 25 May 2004 01: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 1BSUuZ-00036F-AH for ipsec@megatron.ietf.org; Tue, 25 May 2004 01:56:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02477 for ; Tue, 25 May 2004 01:55:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSUuX-0006NY-7u for ipsec@ietf.org; Tue, 25 May 2004 01:55:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSUtb-0006Fi-00 for ipsec@ietf.org; Tue, 25 May 2004 01:54:39 -0400 Received: from zuka.trustworks.com ([212.114.5.147] helo=relay1.trustworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BSUsj-00067c-00 for ipsec@ietf.org; Tue, 25 May 2004 01:53:45 -0400 Received: by relay1.trustworks.com (8.8.5/%I%) id JAA00040; Tue, 25 May 2004 09:54:11 +0400 (MSD) Received: from localhost(127.0.0.1) by zuka via smap (V2.0) id xma029986; Tue, 25 May 04 09:54:00 +0400 Message-ID: <035501c4421c$c1590250$640572d4@trustworks.com> From: "Valery Smyslov" To: "Theodore Ts'o" References: Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Date: Tue, 25 May 2004 09:54:34 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > QUESTION 1: Select one of the following ___ Method #3 (stateful fragment inspection) should be SHOULD or MUST) > QUESTION 2: Should Method #2 (non-initial fragments) be: > (you may pick more than one) ___ MAY > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > (you may pick more than one) ___ SHOULD Regards, Valery Smyslov. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 25 06:39: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 GAA00215 for ; Tue, 25 May 2004 06:39: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 1BSZFp-0005sP-Pd; Tue, 25 May 2004 06:33:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSZ60-0003hq-Ag for ipsec@megatron.ietf.org; Tue, 25 May 2004 06:23:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29332 for ; Tue, 25 May 2004 06:23:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSZ5x-0006g9-T3 for ipsec@ietf.org; Tue, 25 May 2004 06:23:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSZ52-0006TP-00 for ipsec@ietf.org; Tue, 25 May 2004 06:22:45 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BSZ43-0006Fe-00 for ipsec@ietf.org; Tue, 25 May 2004 06:21:44 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i4PALiGQ017322 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 May 2004 13:21:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i4PALgWw017319; Tue, 25 May 2004 13:21:42 +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: <16563.7734.16390.523959@fireball.kivinen.iki.fi> Date: Tue, 25 May 2004 13:21:42 +0300 From: Tero Kivinen To: Satoshi Inoue Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) In-Reply-To: <20040525132331.17fd0d71.inoue@ntes.ipv6.nec.co.jp> References: <20040525132331.17fd0d71.inoue@ntes.ipv6.nec.co.jp> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 11 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Satoshi Inoue writes: > BTW, is fragmented user traffic (i.e. forwarding packets that are > already fragmented, not the ones that are fragmented by IPsec tunnel > I/F MTU size) affected by this? We are only talking about those packets. I.e packets that are already fragmented when the arrive the SGW, and which should be put to the tunnel, and the tunnel SAs have port selectors. > or is it out of scope in this section? No it is the whole scope of the section. > How about fragmented user traffic that is too big for an outgoing > IPsec tunnel's MTU size? There is who issues combined there. If user sends 3000 byte UDP packet to port 1234, which is fragmented to two 1500 byte packets. The SGW will get those two. It now needs to find the proper SA to send them. If SGW have IPsec SA (SA1) with port selectors matching the packet to port 1234, he will send the first of those fragments to that SA. The question is what to do the second fragment. It does not have port numbers, thus he cannot select the SA for it. The proposal #3 says, that ok, we have seen the first fragment, thus we can put up information that if we see other fragments to that packet, send them to same SA1. The proposal #2 says that we need to have specific SA2 for non-first fragments, and we send all non-first fragments to there regardless of their port numbers. So if user then send another 3000 byte UDP packet to port 2345, then the #3 system will drop both fragments, as they do not match the policy. The #2 system will drop the first fragment, as it does not match the policy, but it will pass the second fragment as it matches the policy of the non-first fragment SA (SA2). Now, when we have the SA selected, we can do the actual encryption. If that cause the packet to be too big for the MTU, the resulting encrypted IPsec packet can be then fragmented again. This fragmentation is removed in the other ends SGW, when it needs to reassemble the packet before it can decrypt the packet. This section is NOT covering that at all, it is completely outside the of this section. This is covered elsewhere in the architecture document. > > Another point which has been discussed is how difficult it is to > > implement stateful fragment inspection. Tero has pointed out that his > > implementation has supported this for quite some time, and it isn't > > particularly difficult. > > Just one clarification, could this implementation work out re-ordered/ > non-ordered fragments OK? Yes. If the non-first fragment arrives first, then it is queued in separate fixed length queue for waiting the first-fragment to arrive. When it arrives and the SA is selected, an entry is put to the stateful fragmentation code which will know that rest of the fragments to the same packets should be sent to the same SA. After that entry is put to the cache, the queue of non-first fragments is checked, and if there are any fragments which are part of that pakcet, they are also sent forward. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 25 09:08: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 JAA08782 for ; Tue, 25 May 2004 09:08: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 1BSbV1-0006Gf-2R; Tue, 25 May 2004 08:57:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSbRS-0005hM-FR for ipsec@megatron.ietf.org; Tue, 25 May 2004 08:54:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07929 for ; Tue, 25 May 2004 08:54:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSbRR-0007C4-KC for ipsec@ietf.org; Tue, 25 May 2004 08:54:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSbQe-0006ye-00 for ipsec@ietf.org; Tue, 25 May 2004 08:53:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BSbPz-0006km-00 for ipsec@ietf.org; Tue, 25 May 2004 08:52:31 -0400 Received: from [10.20.30.249] (p64.n-nypop04.stsn.com [199.106.91.64]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCqQI4084194; Tue, 25 May 2004 05:52:27 -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, 25 May 2004 08:52:21 -0400 To: "Theodore Ts'o" , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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:15 AM -0400 5/24/04, Theodore Ts'o wrote: >QUESTION 1: Select one of the following > > _X__ Both Methods #2 and Method #3 should be a MAY >QUESTION 2: Should Method #2 (non-initial fragments) be: > _X_ MAY >QUESTION 3: Should Method #3 (stateful fragment inspection) be: > _X_ MAY --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 25 13:14: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 NAA00769 for ; Tue, 25 May 2004 13:14: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 1BSf7Z-0005uy-Sd; Tue, 25 May 2004 12:49:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSeLo-0005zp-KX for ipsec@megatron.ietf.org; Tue, 25 May 2004 12:00:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22297 for ; Tue, 25 May 2004 12:00:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSeLm-0005oq-CY for ipsec@ietf.org; Tue, 25 May 2004 12:00:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSeKe-0005fn-00 for ipsec@ietf.org; Tue, 25 May 2004 11:59:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BSeJp-0005TA-00 for ipsec@ietf.org; Tue, 25 May 2004 11:58:21 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 May 2004 08:06:29 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4PFvnls024250; Tue, 25 May 2004 08:57:49 -0700 (PDT) Received: from [10.10.10.8] (sjc-vpn2-575.cisco.com [10.21.114.63]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APG03126; Tue, 25 May 2004 08:57:48 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 25 May 2004 08:57:41 -0700 Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) From: Bora Akyol To: "Theodore Ts'o" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 On 5/23/04 10:15 PM, "Theodore Ts'o" wrote: > > QUESTION 1: Select one of the following > > __X_ Both Methods #2 and Method #3 should be a MAY > > ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST > > ___ Method #2 (non-initial fragments get sent to an OPAQUE > SA) should be be SHOULD or MUST > > ___ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > ___ Both Method #2 and #3 should be SHOULD or MUST > > > (In contrast, method #2 is very easy to implement, although it is > admittedly less featureful than #3.) > > QUESTION 2: Should Method #2 (non-initial fragments) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > _X_ MAY > > > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > _X_ MAY _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 25 13:19: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 NAA01284 for ; Tue, 25 May 2004 13:19: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 1BSfKp-0001Es-Lu; Tue, 25 May 2004 13:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSf1x-0003xG-KI for ipsec@megatron.ietf.org; Tue, 25 May 2004 12:43:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27133 for ; Tue, 25 May 2004 12:43:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSf1o-0004jh-NY for ipsec@ietf.org; Tue, 25 May 2004 12:43:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSexA-0003v5-00 for ipsec@ietf.org; Tue, 25 May 2004 12:39:01 -0400 Received: from adsl-209-233-19-171.dsl.snfc21.pacbell.net ([209.233.19.171] helo=tardo.org) by ietf-mx with smtp (Exim 4.12) id 1BSer4-0002uW-00 for ipsec@ietf.org; Tue, 25 May 2004 12:32:43 -0400 Received: (qmail+freegate 17273 invoked by alias); 25 May 2004 16:21:34 -0000 Received: from ws20-n0.hq.tardo.org (HELO p4tardo) (172.16.18.20) by hq.tardo.org with SMTP; 25 May 2004 16:21:34 -0000 Message-Id: <4.2.0.58.20040525092945.00ae6f00@mailhost.hq.tardo.org> X-Sender: tardo@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 25 May 2004 09:35:37 -0700 To: "Theodore Ts'o" , ipsec@ietf.org From: Joseph Tardo Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=UPPERCASE_25_50 autolearn=no version=2.60 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 01:15 AM 5/24/2004 -0400, Theodore Ts'o wrote: >QUESTION 1: Select one of the following > > ____ Both Methods #2 and Method #3 should be a MAY > > _X__One or both of Methods #2 and #3 should be a SHOULD or a MUST > > ___ Method #2 (non-initial fragments get sent to an OPAQUE > SA) should be be SHOULD or MUST > > __X_ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > ___ Both Method #2 and #3 should be SHOULD or MUST > > >QUESTION 2: Should Method #2 (non-initial fragments) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > __X_ MAY writein: SHOULD NOT (provide security caveat text) >QUESTION 3: Should Method #3 (stateful fragment inspection) be: > > (you may pick more than one) > > ___ MUST > > _X__ SHOULD > > ___ MAY > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 25 18:08: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 SAA26811 for ; Tue, 25 May 2004 18:08: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 1BSjeN-00047S-QS; Tue, 25 May 2004 17:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSiLf-0001Xo-7W for ipsec@megatron.ietf.org; Tue, 25 May 2004 16:16:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14799 for ; Tue, 25 May 2004 16:16:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSiLR-0001kW-9S for ipsec@ietf.org; Tue, 25 May 2004 16:16:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSiKR-0001cz-00 for ipsec@ietf.org; Tue, 25 May 2004 16:15:15 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BSiJR-0001Ui-00 for ipsec@ietf.org; Tue, 25 May 2004 16:14:13 -0400 Received: from adsl-69-107-95-131.dsl.pltn13.pacbell.net ([69.107.95.131] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BSiJQ-0006PW-00; Tue, 25 May 2004 16:14:13 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1BSiJQ-0000x4-K6; Tue, 25 May 2004 16:14:12 -0400 Date: Tue, 25 May 2004 16:14:12 -0400 From: "Theodore Ts'o" To: Charlie Kaufman Subject: Re: [Ipsec] Proposed Last Call based revisions to IKEv2 Message-ID: <20040525201412.GA3494@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sat, May 15, 2004 at 10:50:15PM -0700, Charlie Kaufman wrote: > Based on the discussion on the list, I believe these are the final edits > to IKEv2. If anyone disagrees, please speak up before I send out -14. Charlie, It's been a week and we received two suggestions. One was Paul's very good suggestion keep the changes regarding fragmentation handling in RFC-2401bis, which has the advantage of avoiding another IETF-wide last call on your document. The other was William Dixon's suggestion for providing better advanced handling support, which as Russ has pointed out can be done independently without blocking the progress of the IKEv2 draft. Barbara and I believe you should accept Paul's suggestion, and not make any changes to IKEv2 in response to points raised by William Dixon on this thread. If he would like to do that work as a separate draft, in another working group, it appears that the Area Directors will be receptive to such an approach. If you could get -14 published at your earlier convenience, we will then inform Russ that all of the comments raised during the IETF last call process have been resolved, and he should proceed with the getting IESG approval for publishing IKEv2 as a standards-track RFC. Many thanks for all of your very hard work, - Ted and Barbara _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 25 19:12: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 TAA05937 for ; Tue, 25 May 2004 19:12: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 1BSkpo-0001j1-RX; Tue, 25 May 2004 18:55:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSke1-0004ZR-G6 for ipsec@megatron.ietf.org; Tue, 25 May 2004 18:43:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02313 for ; Tue, 25 May 2004 18:43:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSkdz-00038T-2p for ipsec@ietf.org; Tue, 25 May 2004 18:43:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSkad-0002YD-00 for ipsec@ietf.org; Tue, 25 May 2004 18:40:08 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BSkWt-0001or-00 for ipsec@ietf.org; Tue, 25 May 2004 18:36:15 -0400 Received: from rs9.luxsci.com ([66.216.98.59]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BSkIC-0005Lf-3A for ipsec@ietf.org; Tue, 25 May 2004 18:21:04 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i4PMKRwa029273 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 25 May 2004 17:20:27 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i4PMG1OS028529; Tue, 25 May 2004 22:16:01 GMT Message-Id: <200405252216.i4PMG1OS028529@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Tue, 25 May 2004 22:16:01 +0000 From: "William Dixon" To: "'Theodore Ts'o'" , "'Charlie Kaufman'" Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 Date: Tue, 25 May 2004 18:15:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20040525201412.GA3494@thunk.org> X-Lux-Comment: LuxSci remailer message ID code - 1085523361-4322802.60988847 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 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 Fine with me. I wasn't trying to delay the IKEv2 document, thus I suggested another one. I'll post a follow-up to assess the interest in an attack draft when I'm able to start work on it. > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Theodore Ts'o > Sent: Tuesday, May 25, 2004 4:14 PM > To: Charlie Kaufman > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] Proposed Last Call based revisions to IKEv2 > > On Sat, May 15, 2004 at 10:50:15PM -0700, Charlie Kaufman wrote: > > Based on the discussion on the list, I believe these are the final > > edits to IKEv2. If anyone disagrees, please speak up before > I send out -14. > > Charlie, > > It's been a week and we received two suggestions. One was > Paul's very good suggestion keep the changes regarding > fragmentation handling in RFC-2401bis, which has the > advantage of avoiding another IETF-wide last call on your > document. The other was William Dixon's suggestion for > providing better advanced handling support, which as Russ has > pointed out can be done independently without blocking the > progress of the IKEv2 draft. Barbara and I believe you > should accept Paul's suggestion, and not make any changes to > IKEv2 in response to points raised by William Dixon on this > thread. If he would like to do that work as a separate > draft, in another working group, it appears that the Area > Directors will be receptive to such an approach. > > If you could get -14 published at your earlier convenience, > we will then inform Russ that all of the comments raised > during the IETF last call process have been resolved, and he > should proceed with the getting IESG approval for publishing > IKEv2 as a standards-track RFC. > > Many thanks for all of your very hard work, > > - Ted and Barbara > > _______________________________________________ > 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 May 25 22:34: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 WAA16206 for ; Tue, 25 May 2004 22:34: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 1BSoBQ-0006Lu-NV; Tue, 25 May 2004 22:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSo2l-0004cQ-GZ for ipsec@megatron.ietf.org; Tue, 25 May 2004 22:21:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15815 for ; Tue, 25 May 2004 22:21:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSo2j-00065J-GT for ipsec@ietf.org; Tue, 25 May 2004 22:21:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSo1q-0005zb-00 for ipsec@ietf.org; Tue, 25 May 2004 22:20:27 -0400 Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by ietf-mx with esmtp (Exim 4.12) id 1BSo0r-0005pX-00 for ipsec@ietf.org; Tue, 25 May 2004 22:19:25 -0400 Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by TYO201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i4Q2Irp04438 for ; Wed, 26 May 2004 11:18:53 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i4Q2IrM15444 for ipsec@ietf.org; Wed, 26 May 2004 11:18:53 +0900 (JST) Received: from ncos.nec.co.jp (mailgate2.ncos.nec.co.jp [10.40.15.12]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with SMTP id i4Q2Iqm04880 for ; Wed, 26 May 2004 11:18:52 +0900 (JST) Received: (qmail 5925 invoked by uid 0); 26 May 2004 11:18:52 +0900 Received: from unknown (HELO platini.ntes.ipv6.nec.co.jp) (10.43.90.28) by 172.16.255.130 with SMTP; 26 May 2004 11:18:52 +0900 Received: from bn4p0048.bn4.bbn.ncos.nec.co.jp ([IPv6:5ffe:26:2591:1:203:47ff:feb1:ba04]) by platini.ntes.ipv6.nec.co.jp (8.12.11/8.12.11) with SMTP id i4Q2IpK6052573 for ; Wed, 26 May 2004 11:18:52 +0900 (JST) (envelope-from inoue@ntes.ipv6.nec.co.jp) Date: Wed, 26 May 2004 11:18:51 +0900 From: Satoshi Inoue To: ipsec@ietf.org Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Message-Id: <20040526111851.6b759fe3.inoue@ntes.ipv6.nec.co.jp> In-Reply-To: <16563.7734.16390.523959@fireball.kivinen.iki.fi> References: <20040525132331.17fd0d71.inoue@ntes.ipv6.nec.co.jp> <16563.7734.16390.523959@fireball.kivinen.iki.fi> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 On Tue, 25 May 2004 13:21:42 +0300 Tero Kivinen wrote: > > BTW, is fragmented user traffic (i.e. forwarding packets that are > > already fragmented, not the ones that are fragmented by IPsec tunnel > > I/F MTU size) affected by this? > > We are only talking about those packets. I.e packets that are already > fragmented when the arrive the SGW, and which should be put to the > tunnel, and the tunnel SAs have port selectors. Thank you for your explanation. I think I'm on the right track now :-) _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 26 00:14: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 AAA20248 for ; Wed, 26 May 2004 00:14: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 1BSpiA-0003Ez-FL; Wed, 26 May 2004 00:08:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSpWr-0000WE-Vt for ipsec@megatron.ietf.org; Tue, 25 May 2004 23:56:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19584 for ; Tue, 25 May 2004 23:56:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSpWp-0007Ks-PF for ipsec@ietf.org; Tue, 25 May 2004 23:56:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSpVs-0007EW-00 for ipsec@ietf.org; Tue, 25 May 2004 23:55:32 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BSpVX-00078A-00 for ipsec@ietf.org; Tue, 25 May 2004 23:55: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 i4Q3rcc12104 for ; Tue, 25 May 2004 23:53:38 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4Q3qfK1015882 for ; Tue, 25 May 2004 23:52:41 -0400 (EDT) Received: from unknown(203.199.214.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4Caa_E; Tue, 25 May 04 23:52:32 -0400 Date: Wed, 26 May 2004 09:15:29 +0530 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rxrazndmsffoityyovgd" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Fax Message Received 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 ----------rxrazndmsffoityyovgd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rxrazndmsffoityyovgd Content-Type: text/html; name="the_message.vbs.htm" Content-Disposition: attachment; filename="the_message.vbs.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: the_message.vbs
Virus name: W32/Bagle

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

----------rxrazndmsffoityyovgd 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 ----------rxrazndmsffoityyovgd-- From ipsec-bounces@ietf.org Wed May 26 05:42: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 FAA02962 for ; Wed, 26 May 2004 05:42: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 1BSuiC-0004v3-MI; Wed, 26 May 2004 05:28:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BStQj-0003yR-CG for ipsec@megatron.ietf.org; Wed, 26 May 2004 04:06:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28287 for ; Wed, 26 May 2004 04:06:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BStQh-0006hO-57 for ipsec@ietf.org; Wed, 26 May 2004 04:06:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BStPU-0006Ol-00 for ipsec@ietf.org; Wed, 26 May 2004 04:05:13 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BStOG-000670-00 for ipsec@ietf.org; Wed, 26 May 2004 04:03:57 -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 i4Q82Mc13185 for ; Wed, 26 May 2004 04:02:22 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4Q81PoT027919 for ; Wed, 26 May 2004 04:01:25 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0baOF2; Wed, 26 May 04 04:01:21 -0400 Date: Wed, 26 May 2004 09:09:29 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------arfzrltsqvlqyyhcmjod" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Text 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 ----------arfzrltsqvlqyyhcmjod Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------arfzrltsqvlqyyhcmjod Content-Type: text/html; name="Nervous_illnesses.cpl.htm" Content-Disposition: attachment; filename="Nervous_illnesses.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: Nervous_illnesses.cpl
Virus name: W32/Bagle.aa@MM

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

----------arfzrltsqvlqyyhcmjod 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 ----------arfzrltsqvlqyyhcmjod-- From ipsec-bounces@ietf.org Wed May 26 09:57:21 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 JAA16880 for ; Wed, 26 May 2004 09:57:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSymm-00088s-K4; Wed, 26 May 2004 09:49:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSycG-0004oR-T0 for ipsec@megatron.ietf.org; Wed, 26 May 2004 09:38:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16250 for ; Wed, 26 May 2004 09:38:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSycG-0005zP-7s for ipsec@ietf.org; Wed, 26 May 2004 09:38:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSybJ-0005mk-00 for ipsec@ietf.org; Wed, 26 May 2004 09:37:45 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BSyaM-0005W5-00 for ipsec@ietf.org; Wed, 26 May 2004 09:36:46 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i4QDaduG011904; Wed, 26 May 2004 16:36:39 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i4QDacs7011901; Wed, 26 May 2004 16:36:38 +0300 Date: Wed, 26 May 2004 16:36:38 +0300 Message-Id: <200405261336.i4QDacs7011901@burp.tkv.asdf.org> From: Markku Savela To: tytso@mit.edu In-reply-to: (tytso@mit.edu) Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > QUESTION 1: Select one of the following > > _X__ Both Methods #2 and Method #3 should be a MAY > > ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST > > ___ Method #2 (non-initial fragments get sent to an OPAQUE > SA) should be be SHOULD or MUST > > ___ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > ___ Both Method #2 and #3 should be SHOULD or MUST But, I would prefer Method #3 should be a MAY (Method #2 MUST NOT) > QUESTION 2: Should Method #2 (non-initial fragments) be: I consider Method #2 "dirty hack". If your policy says that traffic matching a selector must be protected by the specific security, then it should apply to everything, including fragments (initial and non-initial). But, if people insist on having #2 as option, I don't object if it stays as "MAY". > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > ___ MUST > > ___ SHOULD > > _X_ MAY _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 27 00:23: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 AAA13038 for ; Thu, 27 May 2004 00:23: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 1BTCIB-0000P4-4i; Thu, 27 May 2004 00:14:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTCBq-0006mt-Rh for ipsec@megatron.ietf.org; Thu, 27 May 2004 00:08:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12262 for ; Thu, 27 May 2004 00:08:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTCBo-0004DY-QI for ipsec@ietf.org; Thu, 27 May 2004 00:08:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTCAr-00045M-00 for ipsec@ietf.org; Thu, 27 May 2004 00:07:21 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTCAX-0003xC-00 for ipsec@ietf.org; Thu, 27 May 2004 00:07:01 -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 i4R45Pc16051 for ; Thu, 27 May 2004 00:05:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4R3jJcK013617 for ; Wed, 26 May 2004 23:45:19 -0400 (EDT) Received: from unknown(203.199.214.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAGRaaJA; Wed, 26 May 04 23:45:16 -0400 Date: Thu, 27 May 2004 09:17:30 +0530 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xdgjlghxkmtabruaofex" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: 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 ----------xdgjlghxkmtabruaofex Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------xdgjlghxkmtabruaofex Content-Type: text/html; name="Your_complaint.com.htm" Content-Disposition: attachment; filename="Your_complaint.com.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: Your_complaint.com
Virus name: W32/Bagle.aa@MM

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

----------xdgjlghxkmtabruaofex 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 ----------xdgjlghxkmtabruaofex-- From ipsec-bounces@ietf.org Thu May 27 06:21: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 GAA12954 for ; Thu, 27 May 2004 06:21: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 1BTHmR-0001SF-0T; Thu, 27 May 2004 06:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTGdp-0005hB-F2 for ipsec@megatron.ietf.org; Thu, 27 May 2004 04:53:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08586 for ; Thu, 27 May 2004 04:53:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTGdn-0002qO-3M for ipsec@ietf.org; Thu, 27 May 2004 04:53:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTGco-0002fS-00 for ipsec@ietf.org; Thu, 27 May 2004 04:52:31 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTGcE-0002Uk-00 for ipsec@ietf.org; Thu, 27 May 2004 04:51:54 -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 i4R8oIc27059 for ; Thu, 27 May 2004 04:50:18 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4R8nMcJ001238 for ; Thu, 27 May 2004 04:49:22 -0400 (EDT) Received: from mail.biodata.de(217.7.95.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAALKaGzc; Thu, 27 May 04 04:49:19 -0400 Received: from Unknown [172.16.1.11] by mail.biodata.com - SurfControl E-mail Filter (4.7); Thu, 27 May 2004 10:53:10 +0200 Message-ID: <24EA9B0638C2AD448F3C2E95E3209ECF806084@shrdc1.biodata.com> From: "Nicolas Saurbier" To: "Tislabs (E-Mail)" Date: Thu, 27 May 2004 10:49:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 X-SEF-CBB84740-B655-419C-A6D-D08DD68C8A: 1 content-class: urn:content-classes:message Thread-Topic: !!! PLEASE STOP SPAMMING VIRUSES !!! Thread-Index: AcRDx4DovYd+S5d9TrOY2XOEarboEg== X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=EXCUSE_16,LINES_OF_YELLING, MANY_EXCLAMATIONS,PLING_PLING,SUBJ_ALL_CAPS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] !!! PLEASE STOP SPAMMING VIRUSES !!! 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 Thanx, NIC -------------------------------------------- Any e-mail message from Biodata Systems GmbH is sent in good faith but shal= l neither be binding nor construed as constituting a commitment by Biodata = Systems GmbH except where provided for in a written agreement. This e-mail = is intended only for the use of the recipient(s) named above. Any unauthori= sed disclosure, use or dissemination, either in whole or in part, is prohib= ited. If you have received this e-mail in error, please notify the sender i= mmediately via e-mail and delete this e-mail from your system. -------------------------------------------- =20 Biodata Systems GmbH is a specialist manufacturer of Information Security p= roducts -This message has been scanned for all known viruses by 'Biodata BI= GApplication=AE'. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 27 07:50: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 HAA17464 for ; Thu, 27 May 2004 07:50: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 1BTJ0X-0001Gw-SH; Thu, 27 May 2004 07:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTIfi-0004tX-Tl for ipsec@megatron.ietf.org; Thu, 27 May 2004 07:03:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15213 for ; Thu, 27 May 2004 07:03:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTIfg-0004hw-DY for ipsec@ietf.org; Thu, 27 May 2004 07:03:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTIej-0004WL-00 for ipsec@ietf.org; Thu, 27 May 2004 07:02:37 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTIeC-0004Kn-00 for ipsec@ietf.org; Thu, 27 May 2004 07:02:04 -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 i4RB0Sc19355 for ; Thu, 27 May 2004 07:00:29 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4RAxXQ6024187 for ; Thu, 27 May 2004 06:59:33 -0400 (EDT) Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlQaqoV; Thu, 27 May 04 06:59:31 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i4RB1wu02230; Thu, 27 May 2004 14:01:58 +0300 (IDT) In-Reply-To: <24EA9B0638C2AD448F3C2E95E3209ECF806084@shrdc1.biodata.com> References: <24EA9B0638C2AD448F3C2E95E3209ECF806084@shrdc1.biodata.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <460BF700-AFCD-11D8-BD60-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: quoted-printable From: Yoav Nir Subject: Re: [Ipsec] !!! PLEASE STOP SPAMMING VIRUSES !!! Date: Thu, 27 May 2004 14:01:58 +0300 To: "Nicolas Saurbier" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,MANY_EXCLAMATIONS, PLING_PLING autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: "Tislabs \(E-Mail\)" 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've seen such mails with viruses coming from people who use 'pine' on=20= Solaris for their email. It's not their fault. I suppose the mail=20 worm fakes the from address to an SMTP server to hide where the mail is=20= sent from. Take for example the latest "Incoming Message" from uri at lucent.com. =20= Looking at full headers, I see this: from unknown(203.199.214.66) by nutshell.tislabs.com via csmap = (V6.0)=20 id srcAAAGRaaJA; Wed, 26 May 04 23:45:16 -0400 I can't dig up where 203.199.214.66 is, but that is more likely to be=20 the compromised computer then any computer at Lucent. On May 27, 2004, at 11:49 AM, Nicolas Saurbier wrote: > Thanx, > > NIC > > -------------------------------------------- > Any e-mail message from Biodata Systems GmbH is sent in good faith but=20= > shall neither be binding nor construed as constituting a commitment by=20= > Biodata Systems GmbH except where provided for in a written agreement.=20= > This e-mail is intended only for the use of the recipient(s) named=20 > above. Any unauthorised disclosure, use or dissemination, either in=20 > whole or in part, is prohibited. If you have received this e-mail in=20= > error, please notify the sender immediately via e-mail and delete this=20= > e-mail from your system. > -------------------------------------------- > > Biodata Systems GmbH is a specialist manufacturer of Information=20 > Security products -This message has been scanned for all known viruses=20= > by 'Biodata BIGApplication=AE'. > > _______________________________________________ > 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 May 27 09:40:21 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 JAA24887 for ; Thu, 27 May 2004 09:40:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTL0D-0002K3-5s; Thu, 27 May 2004 09:32:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTKrI-00070g-K8 for ipsec@megatron.ietf.org; Thu, 27 May 2004 09:23:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24008 for ; Thu, 27 May 2004 09:23:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTKrH-0005sA-Kq for ipsec@ietf.org; Thu, 27 May 2004 09:23:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTKqO-0005ex-00 for ipsec@ietf.org; Thu, 27 May 2004 09:22:49 -0400 Received: from spsystems.net ([216.126.83.115]) by ietf-mx with esmtp (Exim 4.12) id 1BTKpX-0005Cm-00 for ipsec@ietf.org; Thu, 27 May 2004 09:21:55 -0400 Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i4RDLCtD022810; Thu, 27 May 2004 09:21:12 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i4RDLCwB022809; Thu, 27 May 2004 09:21:12 -0400 (EDT) Date: Thu, 27 May 2004 09:21:12 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: [Ipsec] !!! PLEASE STOP SPAMMING VIRUSES !!! In-Reply-To: <24EA9B0638C2AD448F3C2E95E3209ECF806084@shrdc1.biodata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=MANY_EXCLAMATIONS, PLING_PLING autolearn=no version=2.60 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thu, 27 May 2004, Nicolas Saurbier wrote: > Thanx, There is no point in screaming about it here. None of the people actually on this list is sending the stuff. The garbage is coming from infected Windows machines whose users' address books happen to include this list. (The source addresses are forged, typically selected randomly from the address books.) Henry Spencer henry@spsystems.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 27 12:40: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 MAA06925 for ; Thu, 27 May 2004 12:40: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 1BTNcA-00026A-Ay; Thu, 27 May 2004 12:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTNJ8-0003Yh-L5 for ipsec@megatron.ietf.org; Thu, 27 May 2004 12:00:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04643 for ; Thu, 27 May 2004 12:00:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTNIs-0005yP-O5 for ipsec@ietf.org; Thu, 27 May 2004 12:00:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTNI0-0005h2-00 for ipsec@ietf.org; Thu, 27 May 2004 11:59:28 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTNGy-0005Oa-00 for ipsec@ietf.org; Thu, 27 May 2004 11:58:24 -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 i4RFukc05099 for ; Thu, 27 May 2004 11:56:46 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4RFtp5Y013823 for ; Thu, 27 May 2004 11:55:51 -0400 (EDT) Received: from host-4-239-9-69.midco.net(69.9.239.4) by nutshell.tislabs.com via csmap (V6.0) id srcAAAqhaG_A; Thu, 27 May 04 11:55:49 -0400 Message-ID: <05d401c44403$4a716498$cc40d368@xx-zd763fqcc16l> From: "Cameron Woods" To: Date: Thu, 27 May 2004 10:58:22 -0500 MIME-Version: 1.0 X-Priority: 3 X-Mailer: PHP X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=HTML_70_80, HTML_IMAGE_ONLY_02, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Ready to get some X@N@X? 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="===============0534101295==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0534101295== Content-Type: text/html; charset="ISO-8859-1" Please wait......





To stop getting these? --===============0534101295== 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 --===============0534101295==-- From ipsec-bounces@ietf.org Thu May 27 12:52: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 MAA08399 for ; Thu, 27 May 2004 12:52: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 1BTNnQ-0006bR-FP; Thu, 27 May 2004 12:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTNPI-0005Li-FB for ipsec@megatron.ietf.org; Thu, 27 May 2004 12:07:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05047 for ; Thu, 27 May 2004 12:06:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTNP7-0007j9-Er for ipsec@ietf.org; Thu, 27 May 2004 12:06:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTNOD-0007Ti-00 for ipsec@ietf.org; Thu, 27 May 2004 12:05:54 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BTNNC-0007DW-00 for ipsec@ietf.org; Thu, 27 May 2004 12:04:50 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BTNMx-0003iD-00; Thu, 27 May 2004 12:04:35 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1BTNMu-0005x3-06; Thu, 27 May 2004 12:04:32 -0400 Date: Thu, 27 May 2004 12:04:31 -0400 From: "Theodore Ts'o" To: Henry Spencer Subject: Re: [Ipsec] !!! PLEASE STOP SPAMMING VIRUSES !!! Message-ID: <20040527160431.GA22862@thunk.org> References: <24EA9B0638C2AD448F3C2E95E3209ECF806084@shrdc1.biodata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,MANY_EXCLAMATIONS, PLING_PLING autolearn=no version=2.60 Cc: IP Security List X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thu, May 27, 2004 at 09:21:12AM -0400, Henry Spencer wrote: > There is no point in screaming about it here. None of the people actually > on this list is sending the stuff. The garbage is coming from infected > Windows machines whose users' address books happen to include this list. > (The source addresses are forged, typically selected randomly from the > address books.) Indeed, the only thing which the apparent senders have at fault is being associated with people who have the bad taste to use a Microsoft Outlook or Outlook Express. We are filtering something like 400-500 Spam and virus messages A DAY being sent to the ipsec mailing list. It's only the ones which match valid recipients of the ipsec mailing list (and e-mail address on the white list) that are getting through. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 27 13: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 NAA10444 for ; Thu, 27 May 2004 13: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 1BTOBm-0006KE-VO; Thu, 27 May 2004 12:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTO5s-0003V7-E5 for ipsec@megatron.ietf.org; Thu, 27 May 2004 12:51:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08113 for ; Thu, 27 May 2004 12:50:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTO5r-0001tN-CI for ipsec@ietf.org; Thu, 27 May 2004 12:50:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTO33-00014n-00 for ipsec@ietf.org; Thu, 27 May 2004 12:48:06 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTNxu-00001O-00 for ipsec@ietf.org; Thu, 27 May 2004 12:42: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 i4RGf9c10301 for ; Thu, 27 May 2004 12:41:09 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4RGeEaK020349 for ; Thu, 27 May 2004 12:40:14 -0400 (EDT) Received: from peacock.verisign.com(65.205.251.73) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_na4UN; Thu, 27 May 04 12:40:12 -0400 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4RGghAO003545 for ; Thu, 27 May 2004 09:42:43 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 May 2004 09:42:43 -0700 Message-ID: From: "Beckloff, Renee" To: Cameron Woods Subject: Out of Office AutoReply: [Ipsec] Ready to get some X@N@X? Date: Thu, 27 May 2004 09:42:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 will be out of the office thru mid June for medical reasons. For any business matters, please forward email to syoung@verisign.com Thank you. Renee _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 27 14:35: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 OAA14732 for ; Thu, 27 May 2004 14:35: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 1BTPbM-0005sD-N1; Thu, 27 May 2004 14:27:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTPZk-0005Ev-LT for ipsec@megatron.ietf.org; Thu, 27 May 2004 14:25:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14247 for ; Thu, 27 May 2004 14:25:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTPZj-0004Oj-9D for ipsec@ietf.org; Thu, 27 May 2004 14:25:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTPYf-00044n-00 for ipsec@ietf.org; Thu, 27 May 2004 14:24:50 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BTPWd-0003Be-00 for ipsec@ietf.org; Thu, 27 May 2004 14:22:43 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 May 2004 11:22:18 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 May 2004 11:22:11 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 27 May 2004 11:20:34 -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] Proposed Last Call based revisions to IKEv2 Date: Thu, 27 May 2004 11:20:42 -0700 Message-ID: Thread-Topic: [Ipsec] Proposed Last Call based revisions to IKEv2 thread-index: AcRDMGhu69eNg7sZSd2RwOk1fjBJ6AA5TL5Q From: "Charlie Kaufman" To: "Theodore Ts'o" X-OriginalArrivalTime: 27 May 2004 18:20:34.0381 (UTC) FILETIME=[4D3A27D0:01C44417] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, ddukes@cisco.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 Can I get a ruling on this one? Notes: 1) The context in which this occurs is when an IKE initiator requests an IPv6 address on the responder's internal network so that it can use it as a source address in its tunneled packets and responses will be routed back to the IKE responder. This is important when the IKE responder is not on the path between the IKE initiator and all of the nodes it will be talking to over the SA. In almost all cases, the NETMASK is irrelevant. If NETMASK were relevant, it should be included in the INTERNAL_IP6_SUBNET attribute, which is already encoded as proposed below. 2) Perhaps I'm confused, but it's my understanding that a NETMASK is just a very inefficient encoding of a prefix length (both in IP4 and IP6). That a NETMASK containing anything other than a series of '1' bits followed by a series of '0' bits is unsupported by almost everything. So I would favor leaving it alone, but I don't think it will break anything if we change it. --Charlie -----Original Message----- From: Darren Dukes (ddukes) [mailto:ddukes@cisco.com]=20 Sent: Wednesday, May 26, 2004 7:49 AM To: 'Theodore Ts'o'; Charlie Kaufman Cc: ipsec@ietf.org Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 I've noticed a problem in the configuration payload section that I believe Steven Kent, and another individual had warned me about many months ago, and I thought I had requested a change for but apparently never did. The problem is that an INTERNAL_IP6_NETMASK field is defined and this makes no sense in IPv6. The change I propose now is to extend the INTERNAL_IP6_ADDRESS type to 17 bytes, the additional byte will be the IPv6 address prefix-length and INTERNAL_IP6_NETMASK should be removed from the document. I apologize to the working group for such an extremely late change, hopefully it can be reviewed and accommodated. On page 78... Change: INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets To: RESERVED 9 =20 Change: INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets To: INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets On page 79... Change: o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the internal network, sometimes called a red node address or private address and MAY be a private address on the Internet. Multiple internal addresses MAY be requested by requesting multiple internal address attributes. The responder MAY only send up to the number of addresses requested. To: o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the internal network, sometimes called a red node address or private address and MAY be a private address on the Internet. Multiple internal addresses MAY be requested by requesting multiple internal address attributes. The responder MAY only send up to the number of addresses requested. The=20 INTERNAL_IP6_ATTRIBUTE is made up of two fields; the first=20 being a 16 octet IPv6 address the second being a one octet=20 prefix-length as defined in [ADDRIPV6]. Also on page 79... Change: o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and reply messages (e.g., 255.255.255.0) and it MUST be used only with an INTERNAL_ADDRESS attribute. To: o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one netmask is allowed in the request and reply messages=20 (e.g., 255.255.255.0) and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute. (Removed INTERNAL_IP6_NETMASK and change INTERNAL_ADDRESS to INTERNAL_IP4_ADDRESS.) Thanks, Darren > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Theodore Ts'o > Sent: Tuesday, May 25, 2004 4:14 PM > To: Charlie Kaufman > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] Proposed Last Call based revisions to IKEv2 >=20 >=20 > On Sat, May 15, 2004 at 10:50:15PM -0700, Charlie Kaufman wrote: > > Based on the discussion on the list, I believe these are=20 > the final edits > > to IKEv2. If anyone disagrees, please speak up before I=20 > send out -14. >=20 > Charlie,=20 >=20 > It's been a week and we received two suggestions. One was Paul's very > good suggestion keep the changes regarding fragmentation handling in > RFC-2401bis, which has the advantage of avoiding another IETF-wide > last call on your document. The other was William Dixon's suggestion > for providing better advanced handling support, which as Russ has > pointed out can be done independently without blocking the progress of > the IKEv2 draft. Barbara and I believe you should accept Paul's > suggestion, and not make any changes to IKEv2 in response to points > raised by William Dixon on this thread. If he would like to do that > work as a separate draft, in another working group, it appears that > the Area Directors will be receptive to such an approach. >=20 > If you could get -14 published at your earlier convenience, we will > then inform Russ that all of the comments raised during the IETF last > call process have been resolved, and he should proceed with the > getting IESG approval for publishing IKEv2 as a standards-track RFC. >=20 > Many thanks for all of your very hard work, >=20 > - Ted and Barbara >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 27 17:02: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 RAA24836 for ; Thu, 27 May 2004 17:02: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 1BTRno-0001IQ-HV; Thu, 27 May 2004 16:48:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTRM8-00030b-0R for ipsec@megatron.ietf.org; Thu, 27 May 2004 16:20:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21942 for ; Thu, 27 May 2004 16:19:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTRM5-0004oC-Ej for ipsec@ietf.org; Thu, 27 May 2004 16:19:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTRL6-0004TQ-00 for ipsec@ietf.org; Thu, 27 May 2004 16:18:57 -0400 Received: from peacock.verisign.com ([65.205.251.73]) by ietf-mx with esmtp (Exim 4.12) id 1BTRK3-0003zA-00 for ipsec@ietf.org; Thu, 27 May 2004 16:17:51 -0400 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i4RKHmq4004050; Thu, 27 May 2004 13:17:48 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 May 2004 13:17:48 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Theodore Ts'o'" , Henry Spencer Subject: RE: [Ipsec] !!! PLEASE STOP SPAMMING VIRUSES !!! Date: Thu, 27 May 2004 13:17:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,MANY_EXCLAMATIONS, PLING_PLING autolearn=no version=2.60 Cc: IP Security List 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 > Indeed, the only thing which the apparent senders have at fault is > being associated with people who have the bad taste to use a Microsoft > Outlook or Outlook Express. That is untrue. The viruses don't just use the address book any more, that is somewhat harder than it once was. These days a lot of viruses scan the messages themselves or documents on the person's computer. > We are filtering something like 400-500 Spam and virus messages A DAY > being sent to the ipsec mailing list. It's only the ones which match > valid recipients of the ipsec mailing list (and e-mail address on the > white list) that are getting through. Are bounce messages sent when a virus is discovered? If so you may well be spamming the person. I get several hundred virus bounce messages every day, as if the virus scanners did not know that the viruses almost all forge email addresses these days. There is more than enough blame to go round for the virus problem. Please do not try to lay everything at the door of your competitors. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 27 17:05: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 RAA24972 for ; Thu, 27 May 2004 17:05: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 1BTRpJ-0003Aa-Om; Thu, 27 May 2004 16:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTRcX-0007Zz-Um for ipsec@megatron.ietf.org; Thu, 27 May 2004 16:36:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23388 for ; Thu, 27 May 2004 16:36:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTRcW-0002Lz-64 for ipsec@ietf.org; Thu, 27 May 2004 16:36:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTRbZ-00025r-00 for ipsec@ietf.org; Thu, 27 May 2004 16:35:58 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BTRac-0001oG-00 for ipsec@ietf.org; Thu, 27 May 2004 16:34:58 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BTRaV-0004cv-00; Thu, 27 May 2004 16:34:51 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1BTRaT-0004bX-Rz; Thu, 27 May 2004 16:34:49 -0400 Date: Thu, 27 May 2004 16:34:49 -0400 From: "Theodore Ts'o" To: "Hallam-Baker, Phillip" Subject: Re: [Ipsec] !!! PLEASE STOP SPAMMING VIRUSES !!! Message-ID: <20040527203449.GA17652@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,MANY_EXCLAMATIONS, PLING_PLING autolearn=no version=2.60 Cc: IP Security List , Henry Spencer X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thu, May 27, 2004 at 01:17:47PM -0700, Hallam-Baker, Phillip wrote: > > We are filtering something like 400-500 Spam and virus messages A DAY > > being sent to the ipsec mailing list. It's only the ones which match > > valid recipients of the ipsec mailing list (and e-mail address on the > > white list) that are getting through. > > Are bounce messages sent when a virus is discovered? If so you may well > be spamming the person. I get several hundred virus bounce messages > every day, as if the virus scanners did not know that the viruses > almost all forge email addresses these days. No, I MANUALLY review the subject lines of all of said mail messages (usually every day, but sometimes travel forces me to skip a day or so), and allow any false positives to be sent on to their destination. (I then put the sender address of said false positive on the whitelist.) All spam/virus mail is then silently dropped. > There is more than enough blame to go round for the virus problem. > Please do not try to lay everything at the door of your competitors. I read my mail on Linux, and am quite positive that I haven't done anything to contribute to the problem. In fact, as a member of the security community, I remember agitating against the sort of rampant featuritis that make e-mail virii possible, a full decade or more ago. But of course, no one in the American Northwest bothered to listen to those of us who saw this problem coming a long, long, LONG time ago. But this has very little to do with IPSEC, so please take any replies to this off-list, please. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 27 17:53: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 RAA28679 for ; Thu, 27 May 2004 17:53: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 1BTSd2-0007qW-Sf; Thu, 27 May 2004 17:41:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTSII-0002vK-VP for ipsec@megatron.ietf.org; Thu, 27 May 2004 17:20:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26519 for ; Thu, 27 May 2004 17:20:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTSIH-0006RP-HP for ipsec@ietf.org; Thu, 27 May 2004 17:20:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTSGF-0005s2-00 for ipsec@ietf.org; Thu, 27 May 2004 17:18:00 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTSFb-0005at-00 for ipsec@ietf.org; Thu, 27 May 2004 17:17:19 -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 i4RLFhc16438 for ; Thu, 27 May 2004 17:15:43 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4RLElZi001866 for ; Thu, 27 May 2004 17:14:47 -0400 (EDT) Received: from dsta-aa751.pivot.net(66.186.175.243) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxdaqNd; Thu, 27 May 04 17:14:45 -0400 Message-ID: <07ba01c44431$82349656$0e8e4482@kentc-comp> From: "Hailey Jackson" To: Date: Thu, 27 May 2004 17:21:34 -0400 MIME-Version: 1.0 X-Priority: 3 X-Mailer: PHP X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Get software for pennies on the dollar. 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="===============1910987553==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1910987553== Content-Type: text/html; charset="ISO-8859-1" Tons of cool software at incredibly low prices
We have all the leading software you can think of!
Windows XP Professional and Office XP Professional for as low as 80 clams.
Buy here!
The stock is limited
The offer is valid till May, 31st
Hurry!





To stop these mails? --===============1910987553== 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 --===============1910987553==-- From ipsec-bounces@ietf.org Thu May 27 18:41: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 SAA01991 for ; Thu, 27 May 2004 18:41: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 1BTTFK-0000M6-1S; Thu, 27 May 2004 18:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTSsN-0004WS-Kj for ipsec@megatron.ietf.org; Thu, 27 May 2004 17:57:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28957 for ; Thu, 27 May 2004 17:57:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTSsM-0001jE-6k for ipsec@ietf.org; Thu, 27 May 2004 17:57:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTSrc-0001Qb-00 for ipsec@ietf.org; Thu, 27 May 2004 17:56:37 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BTSqm-00016C-00 for ipsec@ietf.org; Thu, 27 May 2004 17:55:44 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BTSql-0004u0-00; Thu, 27 May 2004 17:55:44 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1BTSqk-0004mr-WB; Thu, 27 May 2004 17:55:43 -0400 Date: Thu, 27 May 2004 17:55:42 -0400 From: "Theodore Ts'o" To: Charlie Kaufman Subject: Re: [Ipsec] Proposed Last Call based revisions to IKEv2 Message-ID: <20040527215542.GB18349@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org, ddukes@cisco.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 Thu, May 27, 2004 at 11:20:42AM -0700, Charlie Kaufman wrote: > Can I get a ruling on this one? If you have the document open and we need to submit a new I-D anyway, my bias would be to fix it, on the grounds of consistency with INTERNAL_IP6_SUBNET. It's easier to fix it now rather than later, and will probably reduce confusion for implementors in the future. Although this does change the on-the-wire encoding, it has the feel of an editorial fix. However, I don't feel strongly about about this, but you asked for a ruling. Tell folks want. If anyone objects, they have 24 hours to do so. If not, go ahead and push the ID out. - Ted > Notes: > > 1) The context in which this occurs is when an IKE initiator requests an > IPv6 address on the responder's internal network so that it can use it > as a source address in its tunneled packets and responses will be routed > back to the IKE responder. This is important when the IKE responder is > not on the path between the IKE initiator and all of the nodes it will > be talking to over the SA. In almost all cases, the NETMASK is > irrelevant. If NETMASK were relevant, it should be included in the > INTERNAL_IP6_SUBNET attribute, which is already encoded as proposed > below. > > 2) Perhaps I'm confused, but it's my understanding that a NETMASK is > just a very inefficient encoding of a prefix length (both in IP4 and > IP6). That a NETMASK containing anything other than a series of '1' bits > followed by a series of '0' bits is unsupported by almost everything. > > So I would favor leaving it alone, but I don't think it will break > anything if we change it. > > --Charlie > > -----Original Message----- > From: Darren Dukes (ddukes) [mailto:ddukes@cisco.com] > Sent: Wednesday, May 26, 2004 7:49 AM > To: 'Theodore Ts'o'; Charlie Kaufman > Cc: ipsec@ietf.org > Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 > > I've noticed a problem in the configuration payload section that I > believe > Steven Kent, and another individual had warned me about many months ago, > and > I thought I had requested a change for but apparently never did. The > problem is that an INTERNAL_IP6_NETMASK field is defined and this makes > no > sense in IPv6. The change I propose now is to extend the > INTERNAL_IP6_ADDRESS type to 17 bytes, the additional byte will be the > IPv6 > address prefix-length and INTERNAL_IP6_NETMASK should be removed from > the > document. > > I apologize to the working group for such an extremely late change, > hopefully it can be reviewed and accommodated. > > On page 78... > Change: > INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets > To: > RESERVED 9 > > Change: > INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets > To: > INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets > > On page 79... > > Change: > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the > internal network, sometimes called a red node address or > private address and MAY be a private address on the Internet. > Multiple internal addresses MAY be requested by requesting > multiple internal address attributes. The responder MAY only > send up to the number of addresses requested. > To: > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the > internal network, sometimes called a red node address or > private address and MAY be a private address on the Internet. > Multiple internal addresses MAY be requested by requesting > multiple internal address attributes. The responder MAY only > send up to the number of addresses requested. The > INTERNAL_IP6_ATTRIBUTE is made up of two fields; the first > being a 16 octet IPv6 address the second being a one octet > prefix-length as defined in [ADDRIPV6]. > > Also on page 79... > Change: > o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal > network's netmask. Only one netmask is allowed in the request > and reply messages (e.g., 255.255.255.0) and it MUST be used > only with an INTERNAL_ADDRESS attribute. > > To: > o INTERNAL_IP4_NETMASK - The internal network's netmask. Only > one netmask is allowed in the request and reply messages > (e.g., 255.255.255.0) and it MUST be used only with an > INTERNAL_IP4_ADDRESS attribute. > > > (Removed INTERNAL_IP6_NETMASK and change INTERNAL_ADDRESS to > INTERNAL_IP4_ADDRESS.) > > Thanks, > Darren > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of Theodore Ts'o > > Sent: Tuesday, May 25, 2004 4:14 PM > > To: Charlie Kaufman > > Cc: ipsec@ietf.org > > Subject: Re: [Ipsec] Proposed Last Call based revisions to IKEv2 > > > > > > On Sat, May 15, 2004 at 10:50:15PM -0700, Charlie Kaufman wrote: > > > Based on the discussion on the list, I believe these are > > the final edits > > > to IKEv2. If anyone disagrees, please speak up before I > > send out -14. > > > > Charlie, > > > > It's been a week and we received two suggestions. One was Paul's very > > good suggestion keep the changes regarding fragmentation handling in > > RFC-2401bis, which has the advantage of avoiding another IETF-wide > > last call on your document. The other was William Dixon's suggestion > > for providing better advanced handling support, which as Russ has > > pointed out can be done independently without blocking the progress of > > the IKEv2 draft. Barbara and I believe you should accept Paul's > > suggestion, and not make any changes to IKEv2 in response to points > > raised by William Dixon on this thread. If he would like to do that > > work as a separate draft, in another working group, it appears that > > the Area Directors will be receptive to such an approach. > > > > If you could get -14 published at your earlier convenience, we will > > then inform Russ that all of the comments raised during the IETF last > > call process have been resolved, and he should proceed with the > > getting IESG approval for publishing IKEv2 as a standards-track RFC. > > > > Many thanks for all of your very hard work, > > > > - Ted and Barbara > > > > _______________________________________________ > > 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 May 27 20:03: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 UAA06121 for ; Thu, 27 May 2004 20:03: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 1BTUVU-000239-IA; Thu, 27 May 2004 19:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTU56-0004Tk-6X for ipsec@megatron.ietf.org; Thu, 27 May 2004 19:14:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03995 for ; Thu, 27 May 2004 19:14:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTU4o-00007l-QN for ipsec@ietf.org; Thu, 27 May 2004 19:14:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTU3f-0007f7-00 for ipsec@ietf.org; Thu, 27 May 2004 19:13:08 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTU3O-0007PA-00 for ipsec@ietf.org; Thu, 27 May 2004 19:12:50 -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 i4RNBCc28268 for ; Thu, 27 May 2004 19:11:12 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4RNAI2V016505 for ; Thu, 27 May 2004 19:10:18 -0400 (EDT) Received: from dsta-aa751.pivot.net(66.186.175.243) by nutshell.tislabs.com via csmap (V6.0) id srcAAALga4oG; Thu, 27 May 04 19:10:16 -0400 Message-ID: <081201c44441$f73a1816$508894b9@kentc-comp> From: "Erin Favreau" To: Date: Thu, 27 May 2004 19:17:08 -0400 MIME-Version: 1.0 X-Priority: 3 X-Mailer: PHP X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,BIZ_TLD,HTML_40_50, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Save tons of money on Photoshop 7 $60 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="===============1498765979==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1498765979== Content-Type: text/html; charset="ISO-8859-1" We have all the OEM software at incredibly low prices
We have all the leading software you can think of!
Windows XP Professional and Office XP Professional for as low as 80 dollars.
Buy here!
The stock is limited
The offer is valid till May, 31st
Hurry!





To stop getting these? --===============1498765979== 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 --===============1498765979==-- From ipsec-bounces@ietf.org Fri May 28 01:43: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 BAA20691 for ; Fri, 28 May 2004 01:43: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 1BTZwo-00088s-LA; Fri, 28 May 2004 01:30:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTZsv-00075V-IP for ipsec@megatron.ietf.org; Fri, 28 May 2004 01:26:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20083 for ; Fri, 28 May 2004 01:26:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTZst-0003eP-Ck for ipsec@ietf.org; Fri, 28 May 2004 01:26:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTZrx-0003Li-00 for ipsec@ietf.org; Fri, 28 May 2004 01:25:26 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTZrL-000331-00 for ipsec@ietf.org; Fri, 28 May 2004 01:24: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 i4S5NBc16419 for ; Fri, 28 May 2004 01:23:11 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4S5MGNf019318 for ; Fri, 28 May 2004 01:22:16 -0400 (EDT) Received: from unknown(218.65.121.244) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPOaaUL; Fri, 28 May 04 01:22:13 -0400 X-Message-Info: FB6E0XU1caGUU182KYR98aHOYzmN90 Received: from [168.108.190.76] by yemen82835.movie.ipsec@lists.tislabs.com via HTTP; Fri, 28 May 2004 08:30:34 +0300 Date: Fri, 28 May 2004 03:27:34 -0200 Message-ID: <7054927103.14328@ipsec@lists.tislabs.com> From: "Chadwick Morrison" To: "Ipsec" Date: Fri, 28 May 2004 02:35:34 -0300 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Ipsec] 612014 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chadwick Morrison List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0583902444==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0583902444== Content-Type: multipart/alternative; boundary="--52943116408640470" ----52943116408640470 Content-Type: text/html; charset="iso-3022-6" Content-Transfer-Encoding: 7Bit Ipsec, Looking for not expensive high-quality software?
We might have just what you need.

Windows XP Professional 2002 ............. $50
Adobe Photoshop 7.0 ...................... $60
Microsoft Office XP Professional 2002 .... $60
Corel Draw Graphics Suite 11 ............. $60

and lots more...
----52943116408640470-- --===============0583902444== 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 --===============0583902444==-- From ipsec-bounces@ietf.org Fri May 28 04:15: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 EAA11421 for ; Fri, 28 May 2004 04:15: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 1BTc6a-0004te-3c; Fri, 28 May 2004 03:48:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTbuA-0002Gl-FX for ipsec@megatron.ietf.org; Fri, 28 May 2004 03:35:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09974 for ; Fri, 28 May 2004 03:35:33 -0400 (EDT) From: Mika.Joutsenvirta@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTbtt-0000SR-6f for ipsec@ietf.org; Fri, 28 May 2004 03:35:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTbt9-00008D-00 for ipsec@ietf.org; Fri, 28 May 2004 03:34:48 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BTbsX-0007aN-00 for ipsec@ietf.org; Fri, 28 May 2004 03:34:09 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4S7Y0E05772; Fri, 28 May 2004 10:34:01 +0300 (EET DST) X-Scanned: Fri, 28 May 2004 10:31:51 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i4S7VpGH031642; Fri, 28 May 2004 10:31:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00k2deg4; Fri, 28 May 2004 10:31:46 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4S7VeH26137; Fri, 28 May 2004 10:31:40 +0300 (EET DST) Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 May 2004 10:31:37 +0300 Received: from trebe001.NOE.Nokia.com ([172.22.232.171]) by esebe022.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 May 2004 10:31:33 +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] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Date: Fri, 28 May 2004 10:31:32 +0300 Message-ID: <745CAFCB000ABE4588C309477108B50E02962BD6@trebe001.europe.nokia.com> Thread-Topic: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) Thread-Index: AcRBW5t0tV7rTfHfTRyyKk6jI0TsQADKLzHQ To: , X-OriginalArrivalTime: 28 May 2004 07:31:33.0337 (UTC) FILETIME=[CCF82490:01C44485] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME, UPPERCASE_25_50 autolearn=no version=2.60 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 > QUESTION 1: Select one of the following >=20 > __X__ Both Methods #2 and Method #3 should be a MAY >=20 > ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST >=20 > ___ Method #2 (non-initial fragments get sent to an OPAQUE > SA) should be be SHOULD or MUST >=20 > ___ Method #3 (stateful fragment inspection) should be=20 > SHOULD or MUST) >=20 > ___ Both Method #2 and #3 should be SHOULD or MUST >=20 >=20 > QUESTION 2: Should Method #2 (non-initial fragments) be:=20 >=20 > (you may pick more than one) >=20 > ___ MUST >=20 > ___ SHOULD >=20 > _X_ MAY >=20 >=20 > QUESTION 3: Should Method #3 (stateful fragment inspection) be:=20 >=20 > (you may pick more than one) >=20 > ___ MUST >=20 > ___ SHOULD >=20 > _X_ MAY >=20 >=20 Mika _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 28 05:47: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 FAA16009 for ; Fri, 28 May 2004 05:47: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 1BTdlM-0005iB-K3; Fri, 28 May 2004 05:34:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTdbh-00046d-1o for ipsec@megatron.ietf.org; Fri, 28 May 2004 05:24:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15015 for ; Fri, 28 May 2004 05:24:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTdbK-0007Z7-MQ for ipsec@ietf.org; Fri, 28 May 2004 05:24:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTdaK-0007BK-00 for ipsec@ietf.org; Fri, 28 May 2004 05:23:29 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTdZG-0006ct-00 for ipsec@ietf.org; Fri, 28 May 2004 05:22:22 -0400 Received: from 192.94.214.101 ([210.177.127.115]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i4S9Kic21787 for ; Fri, 28 May 2004 05:20:44 -0400 (EDT) X-Message-Info: 8bSIdN69VbF7Q4PExMVggzrqqJzAi54B Received: from domingo.disruptive.com ([52.144.10.206]) by tg9-x23.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 30 May 2004 02:04:24 -0700 Received: from tall.adjectival.com (academic.breakthrough.com [46.48.16.40]) by blocky.desperate.com (8.12.10/8.12.9) with ESMTP id n9BJBsWO260402 for ; Sun, 30 May 2004 07:04:24 -0200 (EST) (envelope-from ipsec@portal.gw.tislabs.com) Received: from ZN986625405592 (modemcable889.912-004-57.bk.videotron.ca [0.119.130.240]) (authenticated bits=0) by arteriole.circuitry.com (8.12.10/8.12.9) with ESMTP id r3QRH6ox189985 for ; Sun, 30 May 2004 03:08:24 -0600 (EST) (envelope-from ipsec@portal.gw.tislabs.com) Message-ID: <626290q1sfv9$mq6s2c62$2718t9b0@YD554528590684> From: "Rene Graves" To: Date: Sun, 30 May 2004 14:01:24 +0500 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=FORGED_RCVD_NET_HELO autolearn=no version=2.60 Subject: [Ipsec] Hi Ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1865983216==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1865983216== Content-Type: multipart/alternative; boundary="--1760966891309563274" ----1760966891309563274 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Ipsec,@ valiumXanaxCialis and_more Get Hydrocodone, or Soma.+ 2 of the best pain killers out! please LQQk) http://www.904.snowballed8493drugs.us/b12 -- brewster cock fatuous radii thyme kind bowel breastwork eratosthenes waylay straightforward immodesty dualism brian olden . ----1760966891309563274-- --===============1865983216== 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 --===============1865983216==-- From ipsec-bounces@ietf.org Fri May 28 05:47:21 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 FAA16026 for ; Fri, 28 May 2004 05:47:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTdls-0005jX-CJ; Fri, 28 May 2004 05:35:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTdbl-000470-Pz for ipsec@megatron.ietf.org; Fri, 28 May 2004 05:24:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15035 for ; Fri, 28 May 2004 05:24:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTdbU-0007aH-GN for ipsec@ietf.org; Fri, 28 May 2004 05:24:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTdaO-0007Bw-00 for ipsec@ietf.org; Fri, 28 May 2004 05:23:33 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTdZS-0006pN-00 for ipsec@ietf.org; Fri, 28 May 2004 05:22:34 -0400 Received: from 192.94.214.101 (btznodw@[218.191.129.91]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i4S9Ktc21844 for ; Fri, 28 May 2004 05:20:56 -0400 (EDT) X-Message-Info: QFLKzFG44eEHuXb465m5+ZRIGn6vBNKK Received: from mail404.xkh.optusnet.com.au ([168.48.234.64]) by rr43-l7.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 30 May 2004 14:02:35 +0500 Received: from QDRZ98 (g32.254.192.251.byznw5.hcp.optusnet.com.au [119.188.68.128]) by mail805.nxl.optusnet.com.au (36.43.8p6/8.85.8) with SMTP id d2L76Bv98663; Sun, 30 May 2004 15:08:35 +0600 Message-ID: <53k414u3ri1c$fv5l01y3$xc8778p4@MGGX11> From: "Alana Cross" To: "Ipsec" References: Date: Sun, 30 May 2004 05:59:35 -0300 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] hiIpsec 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="===============1590793454==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1590793454== Content-Type: multipart/alternative; boundary="--6044238674106988" ----6044238674106988 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Ipsec,% valiumXanaxCialis and_more Get Hydrocodone, or Soma.$ 2 of the best pain killers out! please LQQk( http://www.178.squired5230tabs.us/b12 -- chilean shuffle woodcarver aisle personify decide prototypic radioastronomy ohmic expunge belvedere airfoil chandler boastful cleric inconstant dissension alba charlotte sherry chuck circumpolar affable altogether hellfire shipmate carmichael arrival posy cat edit infidel neutron fluke . ----6044238674106988-- --===============1590793454== 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 --===============1590793454==-- From ipsec-bounces@ietf.org Fri May 28 11:42: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 LAA11013 for ; Fri, 28 May 2004 11:42: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 1BTjIE-0005j0-Cb; Fri, 28 May 2004 11:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTj8u-0003DK-PO for ipsec@megatron.ietf.org; Fri, 28 May 2004 11:19:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08950 for ; Fri, 28 May 2004 11:19:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTj8t-0007F2-VD for ipsec@ietf.org; Fri, 28 May 2004 11:19:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTj6l-0006Ko-00 for ipsec@ietf.org; Fri, 28 May 2004 11:17:20 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTj5J-0005WM-00 for ipsec@ietf.org; Fri, 28 May 2004 11:15:49 -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 i4SFE0r29118 for ; Fri, 28 May 2004 11:14:00 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4SFD6uQ010247 for ; Fri, 28 May 2004 11:13:06 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjraW_t; Fri, 28 May 04 11:12:58 -0400 Date: Fri, 28 May 2004 16:21:10 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yvbgffvqilqoplpchqmb" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Site changes 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 ----------yvbgffvqilqoplpchqmb Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------yvbgffvqilqoplpchqmb Content-Type: text/html; name="Info.vbs.htm" Content-Disposition: attachment; filename="Info.vbs.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: Info.vbs
Virus name: W32/Bagle.aa@MM!vbs

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

----------yvbgffvqilqoplpchqmb 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 ----------yvbgffvqilqoplpchqmb-- From ipsec-bounces@ietf.org Fri May 28 15:35: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 PAA27557 for ; Fri, 28 May 2004 15:35: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 1BTmx7-0005zo-U2; Fri, 28 May 2004 15:23:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTmou-0002LC-Dx for ipsec@megatron.ietf.org; Fri, 28 May 2004 15:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26136 for ; Fri, 28 May 2004 15:15:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTmos-0005Ef-OW for ipsec@ietf.org; Fri, 28 May 2004 15:15:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTmnp-0004oq-00 for ipsec@ietf.org; Fri, 28 May 2004 15:14:02 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTmmk-0004GV-00 for ipsec@ietf.org; Fri, 28 May 2004 15:12:54 -0400 Received: from cm157.omega85.maxonline.com.sg (cm157.omega85.maxonline.com.sg [218.186.85.157]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i4SJB7r01128 for ; Fri, 28 May 2004 15:11:08 -0400 (EDT) Message-Id: <200405281911.i4SJB7r01128@lists.tislabs.com> X-Message-Info: 307B89UWCn60eaqWDieWT05KG25efPmepLM49 Received: from mail pickup service by 218.186.85.157 with Microsoft SMTPSVC; Fri, 28 May 2004 12:19:37 -0700 Content-Class: urn:content-classes:message From: "Pam Blue" To: "Ipsec" Date: Sat, 29 May 2004 00:14:37 +0500 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.9 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Subject: [Ipsec] 231271 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pam Blue List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0930605985==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0930605985== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="--85876918793992448" ----85876918793992448 Content-Type: text/html; charset="iso-2226-7" Content-Transfer-Encoding: 7Bit Ipsec, TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here
----85876918793992448-- --===============0930605985== 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 --===============0930605985==-- From ipsec-bounces@ietf.org Fri May 28 17:49: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 RAA09490 for ; Fri, 28 May 2004 17:49: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 1BToqE-0003hB-VP; Fri, 28 May 2004 17:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BToF2-0001h2-UU for ipsec@megatron.ietf.org; Fri, 28 May 2004 16:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03631 for ; Fri, 28 May 2004 16:46:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BToEz-0006dO-NA for ipsec@ietf.org; Fri, 28 May 2004 16:46:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BToDp-0005nf-00 for ipsec@ietf.org; Fri, 28 May 2004 16:44:57 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BToCL-0005D3-00 for ipsec@ietf.org; Fri, 28 May 2004 16:43:25 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4SKgaJ22350; Fri, 28 May 2004 13:42:36 -0700 (PDT) Message-ID: <40B7A418.5000200@isi.edu> Date: Fri, 28 May 2004 13:42:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" Subject: Re: [Ipsec] STRAW POLL: Handling of fragments in RFC-2401bis (section 7) References: In-Reply-To: X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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="===============1371090820==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1371090820== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig16296057C9E10546A979CD7A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig16296057C9E10546A979CD7A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Theodore Ts'o wrote: > QUESTION 1: Select one of the following > > ____ Both Methods #2 and Method #3 should be a MAY > > ____ One or both of Methods #2 and #3 should be a SHOULD or a MUST > > ___ Method #2 (non-initial fragments get sent to an OPAQUE > SA) should be be SHOULD or MUST > > ___ Method #3 (stateful fragment inspection) should be > SHOULD or MUST) > > ___ Both Method #2 and #3 should be SHOULD or MUST It makes sense to mix non-initial fragments where the initial frags are mixed (Method #1). It makes no security sense to mix some non-initial traffic where the initial fragments are not so mixed. I would consider Method 2 a MUST NOT in that regard. If I have to vote for one of the above, then: __X__ Both Methods #2 and Method #3 should be a MAY > QUESTION 2: Should Method #2 (non-initial fragments) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > ___ MAY Again, I would go MUST NOT. At best, if I have to pick from above, __X__ MAY > QUESTION 3: Should Method #3 (stateful fragment inspection) be: > > (you may pick more than one) > > ___ MUST > > ___ SHOULD > > ___ MAY _X_ MAY --------------enig16296057C9E10546A979CD7A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAt6QYE5f5cImnZrsRAhS4AKDvFsxDcAMlWZ9wHDYxLQW7SnST2QCeItnr qK00t1n5rQY0tpJ2oh57G/w= =9gC0 -----END PGP SIGNATURE----- --------------enig16296057C9E10546A979CD7A-- --===============1371090820== 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 --===============1371090820==-- From ipsec-bounces@ietf.org Sat May 29 04:38: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 EAA21973 for ; Sat, 29 May 2004 04:38: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 1BTzBD-0003Dz-F9; Sat, 29 May 2004 04:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTzA3-00034S-TP for ipsec@megatron.ietf.org; Sat, 29 May 2004 04:25:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21722 for ; Sat, 29 May 2004 04:25:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTzA1-0007Kt-JE for ipsec@ietf.org; Sat, 29 May 2004 04:25:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTz9I-0006xR-00 for ipsec@ietf.org; Sat, 29 May 2004 04:25:01 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BTz8a-0006YM-00 for ipsec@ietf.org; Sat, 29 May 2004 04:24:16 -0400 Received: from S01060010b50061f5.cg.shawcable.net (S01060010b50061f5.cg.shawcable.net [68.147.17.12]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i4T8MZr14447 for ; Sat, 29 May 2004 04:22:36 -0400 (EDT) X-Message-Info: QI8UCE870EQSp8snXheB18DDL3hiWhB4 Received: from j-007-923-773-22.VYGHA18.ipsec@portal.gw.tislabs.com ([68.113.203.64]) by bgcpr673-iuwnl1.ipsec@portal.gw.tislabs.com with Microsoft SMTPSVC(5.0.2918.0402); Sat, 29 May 2004 08:18:15 -0100 Message-ID: <01042360893249867271.19022@ipsec@portal.gw.tislabs.com> X-Originating-IP: [64.241.76.162] X-Originating-Email: [ipsec@portal.gw.tislabs.com] X-Sender: ipsec@portal.gw.tislabs.com From: "Roslyn Aldrich" To: "Ipsec" Date: Sat, 29 May 2004 05:19:15 -0400 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.8 required=5.0 tests=CLICK_BELOW,HTML_70_80, HTML_LINK_CLICK_HERE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PORN_4 autolearn=no version=2.60 Subject: [Ipsec] Fwd: Low cost xanax,valium, soma,etc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Roslyn Aldrich List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1990592146==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1990592146== Content-Type: multipart/alternative; boundary="--94903053527557574627" ----94903053527557574627 Content-Type: text/html; charset="iso-5903-0" Content-Description: elite ado7998.cling Content-Transfer-Encoding: 7Bit birdseed moines consignee wag equanimity nameplate vegetate limestone pooch auditor furlough smooch muon obvious party perfunctory sherrill draco

 
Prozac 
 Vlagra
 Phentermlne
 Soma
 Amblen
Vallum 
 Clalis
 Xanax
Get over 300 medicatlons online shlpped overnight to your front door with no prescrlption.
   *  No Prescrlptlon Needed
   *  Fully Confldential
   *  No Embarrassment
   *  No Waiting Rooms
   *  Shlpped Overnlght
   *  Dlscreet Packaging

 

 

If you wish for email elimination, you can do so here.

 


 


 

 

hereto indent norwegian pond ell paraffin world definitive obscene bate sanctuary dangerous bloodstain disco diffract overt adhere confident vengeance bergstrom rebelling chisholm crimson allocable alliance stygian viscometer xylophone aegean pyrex parent ali longitude tango derby marine soprano claim candy crosswort glottis dilute cried dictionary hood rally coltsfoot datum solder bitt betrothal forceful scythia haunch commission withstood romania bittern kaiser severalfold arrowhead tickle floppy blackberry hoot capitol baptism bawdy neuropsychiatric quebec lymph bogota baudelaire powdery attenuate astigmatism fillet motor cornelia expedite paragon contumacy dodecahedron chine slick byers covenant resistor kiewit boutenfant rudy stumpy defuse eager inadvisable diffident upperclassman inconsequential dessert clattery burlap cafe winnipeg involutorial adorn canberra stripy dissonant molehill photo beatnik pembroke discomfit bergamot situ atreus arbitrary jig blurry seethe needn't mudd novosibirsk psychopath warble doubloon anne clausius myoglobin paddy histamine align rattlesnake distortion basilisk cocaine washington bounty breathe bushel gyrfalcon enormity grub mozart outrageous bungle testify earl megahertz steppe corridor pyrolyse frighten anderson northeastern banbury mcfadden leg bohr ----94903053527557574627-- --===============1990592146== 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 --===============1990592146==-- From ipsec-bounces@ietf.org Sat May 29 06:10: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 GAA25759 for ; Sat, 29 May 2004 06:10: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 1BU0hj-0001qv-0j; Sat, 29 May 2004 06:04:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BU0gp-0001hi-RC for ipsec@megatron.ietf.org; Sat, 29 May 2004 06:03:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25519 for ; Sat, 29 May 2004 06:03:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BU0gn-0005E0-Cl for ipsec@ietf.org; Sat, 29 May 2004 06:03:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BU0fr-0004rM-00 for ipsec@ietf.org; Sat, 29 May 2004 06:02:43 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BU0ex-0004Uw-00 for ipsec@ietf.org; Sat, 29 May 2004 06:01: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 i4TA08r01866 for ; Sat, 29 May 2004 06:00:08 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4T9xGbM002848 for ; Sat, 29 May 2004 05:59:16 -0400 (EDT) Received: from ppp194.as53-2.gill.wy.vcn.com(209.193.79.195) by nutshell.tislabs.com via csmap (V6.0) id srcAAA21a4Hf; Sat, 29 May 04 05:59:13 -0400 Message-ID: <093a01c4456d$83aadc3e$8f5bedb9@l9k5t0> From: "Sam Hardy" To: Date: Sat, 29 May 2004 05:06:09 -0600 MIME-Version: 1.0 X-Priority: 3 X-Mailer: PHP X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Can't beat $50 for MS XP Pro! 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="===============0442555742==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0442555742== Content-Type: text/html; charset="ISO-8859-1" All the software you could want at incredibly low prices
We have all the leading software you can think of!
Windows XP Professional and Office XP Professional for as low as 80 dollars.
Buy here!
The stock is limited
The offer is valid till May, 31st
Hurry!





Would you like to stop reciving these? --===============0442555742== 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 --===============0442555742==-- From ipsec-bounces@ietf.org Sat May 29 06:17: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 GAA26145 for ; Sat, 29 May 2004 06:17: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 1BU0oV-00032Y-BI; Sat, 29 May 2004 06:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BU0it-0001yU-5j for ipsec@megatron.ietf.org; Sat, 29 May 2004 06:05:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25678 for ; Sat, 29 May 2004 06:05:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BU0iq-000616-Ny for ipsec@ietf.org; Sat, 29 May 2004 06:05:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BU0hy-0005ds-00 for ipsec@ietf.org; Sat, 29 May 2004 06:04:55 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BU0hA-0005FX-00 for ipsec@ietf.org; Sat, 29 May 2004 06:04:04 -0400 Received: from cm61-18-72-76.hkcable.com.hk (cm61-18-72-76.hkcable.com.hk [61.18.72.76]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i4TA2Lr02301 for ; Sat, 29 May 2004 06:02:22 -0400 (EDT) X-Message-Info: 46B398YAPf78tRILdGYL342DJ23ncZfJAC668 Received: from v-224-040-8-659.ZMGXV2.ipsec@portal.gw.tislabs.com ([191.200.216.177]) by zgel93-ojgzi815.ipsec@portal.gw.tislabs.com with Microsoft SMTPSVC(5.0.8492.4790); Sat, 29 May 2004 07:57:36 -0200 Message-ID: <6057715458512863.82529@ipsec@portal.gw.tislabs.com> X-Originating-IP: [50.70.2.244] X-Originating-Email: [ipsec@portal.gw.tislabs.com] X-Sender: ipsec@portal.gw.tislabs.com From: "Josie Ohara" To: "Ipsec" Date: Sat, 29 May 2004 08:03:36 -0200 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=BIZ_TLD, SUB_HELLO autolearn=no version=2.60 Subject: [Ipsec] Hello Ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Josie Ohara List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2099315351==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2099315351== Content-Type: multipart/alternative; boundary="--55091688677928562" ----55091688677928562 Content-Type: text/plain; charset="iso-5518-1" Content-Transfer-Encoding: 7Bit Ipsec,% _95%0ff for all-Viagr^a ,C`ialis ,-- L-evitra--. http://lbdowt.HEEHLM.biz/ES001/?affiliate_id=233519&campaign_id=404 -- coinage bellatrix covalent bayda domain trek connector gaylord lavatory shoal basso contrary ----55091688677928562-- --===============2099315351== 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 --===============2099315351==-- From ipsec-bounces@ietf.org Sat May 29 18:01:49 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 SAA23893 for ; Sat, 29 May 2004 18:01:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUBn5-0003Qq-1K; Sat, 29 May 2004 17:54:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUBgk-0002au-DD for ipsec@megatron.ietf.org; Sat, 29 May 2004 17:48:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23549 for ; Sat, 29 May 2004 17:48:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUBgi-0001vJ-Ts for ipsec@ietf.org; Sat, 29 May 2004 17:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUBfj-0001Yn-00 for ipsec@ietf.org; Sat, 29 May 2004 17:47:19 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BUBf4-0001C6-00 for ipsec@ietf.org; Sat, 29 May 2004 17:46:38 -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 i4TLiwr07651 for ; Sat, 29 May 2004 17:44:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4TLi5p4015455 for ; Sat, 29 May 2004 17:44:05 -0400 (EDT) Received: from cs67101-179.houston.rr.com(67.10.1.179) by nutshell.tislabs.com via csmap (V6.0) id srcAAAf4ailE; Sat, 29 May 04 17:44:04 -0400 Message-ID: <032c01c445c6$588193f6$1ec97b71@DPEN> From: "Kiara Giggs" To: Date: Sat, 29 May 2004 16:46:25 -0500 MIME-Version: 1.0 X-Priority: 3 X-Mailer: PHP X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Windows XP & Office XP for $80 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="===============1709089370==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1709089370== Content-Type: text/html; charset="ISO-8859-1" Tons of cool software at incredibly low prices
We have all the leading software you can think of!
Windows XP Professional and Office XP Professional for as low as 80 dollars.
Buy here!
The stock is limited
The offer is valid till May, 31st
Hurry!





no more of these? --===============1709089370== 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 --===============1709089370==-- From ipsec-bounces@ietf.org Sun May 30 03:14:31 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 DAA23607 for ; Sun, 30 May 2004 03:14:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUKIX-0006ro-Vb; Sun, 30 May 2004 02:59:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUKAN-0006D9-NR for ipsec@megatron.ietf.org; Sun, 30 May 2004 02:51:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23152 for ; Sun, 30 May 2004 02:51:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUKAK-0005Pz-UA for ipsec@ietf.org; Sun, 30 May 2004 02:51:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUK9M-00055u-00 for ipsec@ietf.org; Sun, 30 May 2004 02:50:29 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BUK8R-0004SD-00 for ipsec@ietf.org; Sun, 30 May 2004 02:49:31 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 29 May 2004 23:49:07 -0700 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 29 May 2004 23:49:01 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 29 May 2004 23:47: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 29 May 2004 23:47:58 -0700 Message-ID: Thread-Topic: draft-ietf-ipsec-ikev2-14.txt thread-index: AcRGEgtONgNYpgepQoGFDQrhbhwyZA== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 30 May 2004 06:47:18.0457 (UTC) FILETIME=[F35D1A90:01C44611] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] draft-ietf-ipsec-ikev2-14.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 just forwarded it to internet-drafts, copying Paul Hoffman in hopes he will post it on his web page faster than the I-D editor will get to it. This responds to the issues raised during IETF last call. The changes were: H.14 Changes from IKEv2-13 to IKEv2-14 May 2004 1) ISSUE #99: Clarified use of tunnel mode vs. transport mode. 2) Changed the cryptographic formula for computing the AUTH payload in response to a suggestion from Hugo Krawczyk. 3) Fixed a wording error in the explanation of why NAT traversal works as it does related to processing by legacy NAT gateways. 4) Corrected the label AUTH_AES_XCBC_96 to AUTH_AES_PRF_128. 5) Deleted suggestion that ID_KEY_ID field might be used to pass an account name. 6) Listed the newly allocated OID for certificate bundle. 7) Added NON_FIRST_FRAGMENTS_ALSO notification for negotiating the ability to send non-initial fragments of packets on the same SA as the initial fragments. 8) ISSUE #97: Removed language concerning the relative strength of Diffie-Hellman groups. 9) ISSUE #100: Reduced requirements concerning sending of certificates to allow implementations to by more coy about their identities and protect themselves from probing attacks. Listed in Security Considerations some issues an implementer might consider in deciding how to deal with such attacks. 10) Made the punctuation of references to RFCs more consistent. 11) Fixed fourteen typos. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun May 30 23:58: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 XAA11225 for ; Sun, 30 May 2004 23:58: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 1BUdsa-0002TG-A6; Sun, 30 May 2004 23:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUdkv-0001WJ-Uh for ipsec@megatron.ietf.org; Sun, 30 May 2004 23:46:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10599 for ; Sun, 30 May 2004 23:46:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUdkt-0003vd-UQ for ipsec@ietf.org; Sun, 30 May 2004 23:46:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUdjt-0003Zq-00 for ipsec@ietf.org; Sun, 30 May 2004 23:45:30 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BUdix-0003GC-00 for ipsec@ietf.org; Sun, 30 May 2004 23:44:31 -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 i4V3gnr05134 for ; Sun, 30 May 2004 23:42:49 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4V3fwNL027560 for ; Sun, 30 May 2004 23:41:58 -0400 (EDT) Received: from adsl-66-122-60-87.dsl.sntc01.pacbell.net(66.122.60.87) by nutshell.tislabs.com via csmap (V6.0) id srcAAALEaaX1; Sun, 30 May 04 23:41:46 -0400 Date: Mon, 01 Jan 2001 00:13:54 -0800 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------uijipftdkcdynbnrtbut" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=DATE_IN_PAST_96_XX, HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Hello 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 ----------uijipftdkcdynbnrtbut Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------uijipftdkcdynbnrtbut Content-Type: text/html; name="Your_complaint.cpl.htm" Content-Disposition: attachment; filename="Your_complaint.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: Your_complaint.cpl
Virus name: W32/Bagle.aa@MM

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

----------uijipftdkcdynbnrtbut 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 ----------uijipftdkcdynbnrtbut-- From ipsec-bounces@ietf.org Mon May 31 07:04: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 HAA12743 for ; Mon, 31 May 2004 07:04: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 1BUkOl-0007fx-15; Mon, 31 May 2004 06:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUkEr-0006W0-2Z for ipsec@megatron.ietf.org; Mon, 31 May 2004 06:41:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11788 for ; Mon, 31 May 2004 06:41:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUkEg-0006hD-Mw for ipsec@ietf.org; Mon, 31 May 2004 06:41:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUkE9-0006Nv-00 for ipsec@ietf.org; Mon, 31 May 2004 06:41:10 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BUkD5-000640-00 for ipsec@ietf.org; Mon, 31 May 2004 06:40: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 i4VAcLr29277 for ; Mon, 31 May 2004 06:38:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4VAbV8X005412 for ; Mon, 31 May 2004 06:37:31 -0400 (EDT) Received: from cm61-10-115-240.hkcable.com.hk(61.10.115.240) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPZaaIk; Mon, 31 May 04 06:37:28 -0400 X-Message-Info: CO57QBS038HME8iC07WG6asbDNxXB9 Received: from [128.180.192.253] by myra7782.nebraska.ipsec@lists.tislabs.com via HTTP; Wed, 02 Jun 2004 16:45:05 +0600 Date: Wed, 02 Jun 2004 07:47:05 -0300 Message-ID: <04097308203.45909@ipsec@lists.tislabs.com> From: "Colby Sweet" To: "Ipsec" Date: Wed, 02 Jun 2004 04:47:05 -0600 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=HTML_60_70, HTML_IMAGE_ONLY_06, HTML_IMAGE_RATIO_04, HTML_MESSAGE, MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Ipsec] 688648 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Colby Sweet List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0199866883==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0199866883== Content-Type: multipart/alternative; boundary="--09644621233269489" ----09644621233269489 Content-Type: text/html; charset="iso-5148-5" Content-Transfer-Encoding: 7Bit
SaCve 650% ordgering onloine ToGday!

Vi7sit our Site and SaSve Big

bloody arteriolosclerosis muriatic mallard horton frightful emissary sprig experiment solstice cubbyhole bombastic polyhedra dignity cover evensong multitudinous oath transitive argue continuum surfactant procrustean manikin wi thirteenth quasiparticle heterodyne burmese aztecan trumpery lysine gibby yankee proscription sonority essex revolutionary GY4 bondage during conceptual alderman armful contiguity inexact albania heart watery store presuming delouse homily attention canis ejector dAH0 inconsiderableaggressive
rm
----09644621233269489-- --===============0199866883== 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 --===============0199866883==-- From ipsec-bounces@ietf.org Mon May 31 09:22: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 JAA18899 for ; Mon, 31 May 2004 09:22: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 1BUme8-0002kJ-6o; Mon, 31 May 2004 09:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUmX6-0001Zi-HN for ipsec@megatron.ietf.org; Mon, 31 May 2004 09:08:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18294 for ; Mon, 31 May 2004 09:08:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUmX5-0000dm-RJ for ipsec@ietf.org; Mon, 31 May 2004 09:08:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUmWC-0000Jt-00 for ipsec@ietf.org; Mon, 31 May 2004 09:07:56 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BUmVW-0007na-00 for ipsec@ietf.org; Mon, 31 May 2004 09:07:14 -0400 Received: from cm218-252-227-20.hkcable.com.hk (cm218-252-227-20.hkcable.com.hk [218.252.227.20]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i4VD5Rr17974 for ; Mon, 31 May 2004 09:05:28 -0400 (EDT) X-Message-Info: 385P01DAyvr925woLNmuqBKW560Q67iwyBZtZNG07 Received: from 250.73.14.140 by eratosthenes20-sq659.vial06.ipsec@portal.gw.tislabs.com with DAV; Thu, 03 Jun 2004 09:05:01 -0400 Message-ID: <2959330363992701.40410@ipsec@portal.gw.tislabs.com> X-Originating-IP: [182.184.3.80] X-Originating-Email: [ipsec@portal.gw.tislabs.com] X-Sender: ipsec@portal.gw.tislabs.com From: "Margret Friend" To: "Ipsec" Date: Thu, 03 Jun 2004 09:03:01 -0400 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=ONLINE_PHARMACY autolearn=no version=2.60 Subject: [Ipsec] Ipsec r@x tabloid 1 haunches X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Margret Friend List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0339486277==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0339486277== Content-Type: multipart/alternative; boundary="--=====440826336013=_" ----=====440826336013=_ Content-Type: text/plain; charset="iso-5825-6" Content-Transfer-Encoding: 7Bit Ipsec,~ We are going to be closing soon! We have the highest quality, and now, lowest priced prescription drugs online. Buy something while you still can! VI3AGRA C4ialis VALIU+M X7ANAX http://www.385.nonblank4701biz.us/b12 proportion grub riverbank sonorous linen chiton bequest doughnut buffoon desist israelite offal rheumatic dusenberg radices seamen note silt harmful . ----=====440826336013=_-- --===============0339486277== 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 --===============0339486277==-- From ipsec-bounces@ietf.org Mon May 31 09:55: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 JAA20715 for ; Mon, 31 May 2004 09:55: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 1BUn9b-0007H5-4T; Mon, 31 May 2004 09:48:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUmwV-0005l3-5l for ipsec@megatron.ietf.org; Mon, 31 May 2004 09:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19725 for ; Mon, 31 May 2004 09:35:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUmwU-0001tU-Db for ipsec@ietf.org; Mon, 31 May 2004 09:35:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUmvI-0001S0-00 for ipsec@ietf.org; Mon, 31 May 2004 09:33:53 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BUmuB-0000vK-00 for ipsec@ietf.org; Mon, 31 May 2004 09:32:43 -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 i4VDV0r21706 for ; Mon, 31 May 2004 09:31:00 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4VDU9tK029053 for ; Mon, 31 May 2004 09:30:09 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0za4U4; Mon, 31 May 04 09:30:05 -0400 Date: Mon, 31 May 2004 14:38:23 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hshhkwrjcahkepxiijdu" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Forum notify 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 ----------hshhkwrjcahkepxiijdu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------hshhkwrjcahkepxiijdu Content-Type: text/html; name="Smoke.cpl.htm" Content-Disposition: attachment; filename="Smoke.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: Smoke.cpl
Virus name: W32/Bagle.aa@MM

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

----------hshhkwrjcahkepxiijdu 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 ----------hshhkwrjcahkepxiijdu-- From ipsec-bounces@ietf.org Mon May 31 10:28: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 KAA23415 for ; Mon, 31 May 2004 10:28: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 1BUnh4-0001l8-Jc; Mon, 31 May 2004 10:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUndN-0000kD-9c for ipsec@megatron.ietf.org; Mon, 31 May 2004 10:19:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22775 for ; Mon, 31 May 2004 10:19:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUndM-0002CB-HP for ipsec@ietf.org; Mon, 31 May 2004 10:19:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUnc4-0001i9-00 for ipsec@ietf.org; Mon, 31 May 2004 10:18:04 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BUnax-0001GQ-00 for ipsec@ietf.org; Mon, 31 May 2004 10:16:55 -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 i4VEFBr27837 for ; Mon, 31 May 2004 10:15:11 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4VEEL9w005466 for ; Mon, 31 May 2004 10:14:21 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAANZaWPk; Mon, 31 May 04 10:14:17 -0400 Date: Mon, 31 May 2004 15:22:34 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fwauksralrpopepcxvvq" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Hello 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 ----------fwauksralrpopepcxvvq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------fwauksralrpopepcxvvq Content-Type: text/html; name="Info.scr.htm" Content-Disposition: attachment; filename="Info.scr.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: Info.scr
Virus name: W32/Bagle.aa@MM

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

----------fwauksralrpopepcxvvq 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 ----------fwauksralrpopepcxvvq-- From ipsec-bounces@ietf.org Mon May 31 12:39: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 MAA29996 for ; Mon, 31 May 2004 12:39: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 1BUplv-0005TJ-S8; Mon, 31 May 2004 12:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUpdw-0004Jz-BT for ipsec@megatron.ietf.org; Mon, 31 May 2004 12:28:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29253 for ; Mon, 31 May 2004 12:28:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUpdv-0003Fv-ET for ipsec@ietf.org; Mon, 31 May 2004 12:28:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUpcA-0002U3-00 for ipsec@ietf.org; Mon, 31 May 2004 12:26:19 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BUpaN-0001iy-00 for ipsec@ietf.org; Mon, 31 May 2004 12:24: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 i4VGMgr14944 for ; Mon, 31 May 2004 12:22:42 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4VGLqbn023356 for ; Mon, 31 May 2004 12:21:52 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAbLayLT; Mon, 31 May 04 12:21:47 -0400 Date: Mon, 31 May 2004 17:30:03 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rpmrhrsvrfvteweijneg" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Message Notify 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 ----------rpmrhrsvrfvteweijneg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rpmrhrsvrfvteweijneg 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

----------rpmrhrsvrfvteweijneg 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 ----------rpmrhrsvrfvteweijneg--