From ipsec-admin@ietf.org Mon May 3 09:33:26 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i43GXPYS026481; Mon, 3 May 2004 09:33:25 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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

----------tbvglgsxnidyjfylqwcm-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 3 11:12:05 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i43IC1OM046421; Mon, 3 May 2004 11:12:02 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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

----------rgudlfzbhrmkcbtiljhw-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 3 15:53:08 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i43Mr6X3000443; Mon, 3 May 2004 15:53:07 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Mon May 3 19:06:13 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4426BXJ043849; Mon, 3 May 2004 19:06:12 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Tue May 4 10:04:25 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44H4Obe099789; Tue, 4 May 2004 10:04:25 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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: , 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 00:23:33 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i457NWmi034921; Wed, 5 May 2004 00:23:33 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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

----------mvzursoavhtcfsvkfhfl-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed May 5 07:27:42 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45ERfLM029409; Wed, 5 May 2004 07:27:42 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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

----------rdukvytbmckjcupybmfx-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 6 00:50:41 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i467oeI2003016; Thu, 6 May 2004 00:50:41 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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

------=_NextPart_000_0001_00007153.0000645A-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From barristadams@bigpond.com Thu May 6 02:16:52 2004 Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.156]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i469GqFo036974; Thu, 6 May 2004 02:16:52 -0700 (PDT) (envelope-from barristadams@bigpond.com) Received: from lerc-daemon.mta02ps.email.bigpond.com by mta02ps.email.bigpond.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <0HXA001C6BP2QI@mta02ps.email.bigpond.com>; Thu, 06 May 2004 19:00:45 +1000 (EST) Received: from email.bigpond.com ([172.26.103.21]) by mta02ps.email.bigpond.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HXA00GWWBP0HW@mta02ps.email.bigpond.com>; Thu, 06 May 2004 19:00:37 +1000 (EST) Received: from [192.168.115.151] by mailms12ps.email.bigpond.com (mshttpd) ; Thu, 06 May 2004 11:00:36 +0200 Date: Thu, 06 May 2004 11:00:36 +0200 From: barristadams Subject: INHERITANCE CLAIM Message-id: <6e8786d444.6d4446e878@email.bigpond.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.14 (built Nov 18 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Barrister DONALD ADAMS & ASSOCIATE, Alternative email :barristadams@lawyer.com Dear friend I am Barrister Donald Adams , I am the Personal Attorney to MR. JOHN VOELKER , a national of your country, who used to work with shell development company in Nigeria. Died in the plane crash of 21st October 1999[with Egyptian 990] with other passengers aboaed as you can confirm it yourself via the website below:http://www.cnn.com/us/9911/02/egyptair990.list/index.html I have made several enquiries to your Embassy to locate any of my clients extended latives, this has also proved unsuccessful. After these several unsuccessful attempts, I decided to trace his relatives over the Internet, to locate any member of his family but all the attempt was to no avail. I contacted you to assist in repartrating the money and property left behind by my client before they get confiscated or declared unserviceable by the bank where this huge deposits were lodged.Particularly, the Bank where the deceased had an account valued at about $9 million dollars.Consequently,The bank issued me a notice to provide the next of kin or have the account confiscated within the next seven official working days. Since i have been unsuccessfull in locating the the relatives .I seek your consent to present you as the next of kin of the deceased since you are from the same country so that the proceeds of this account valued at $9 million dollars can be paid to you and then you and me can share the money. 55% to me and 40% to you,while 5% should be for expenses or taxes your government may require. I have all necessary legal documents that can be used to back up any claim we may make. All I require is your honest cooperation to enable us see this deal through. I guarantee that this will be executed under a legitimate arrangement that will protect you from any breach of the law.Please get in touch with me via my email. Best regards, Barrister Donald Adams ,Esq. From ipsec-admin@ietf.org Thu May 6 03:16:59 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46AGwL7055038; Thu, 6 May 2004 03:16:59 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 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] 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i46AGwL7055038 Hello all, Does anybody know any IKE implementation with ECDSA support? Thanks, F�lix _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu May 6 06:57:53 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46DvpJ8069514; Thu, 6 May 2004 06:57:53 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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

Dear List,

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 09:21:42 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46GLbU4081267; Thu, 6 May 2004 09:21:39 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 10:18:56 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46HItLQ085928; Thu, 6 May 2004 10:18:55 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Fri May 7 07:20:26 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47EKP9d037708; Fri, 7 May 2004 07:20:26 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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" 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] 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i47EKP9d037708 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 ? Best regards Peter _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri May 7 08:29:56 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47FTsft042153; Fri, 7 May 2004 08:29:55 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Fri May 7 09:59:06 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47Gx4qu050434; Fri, 7 May 2004 09:59:05 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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: , 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 10:39:34 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47HdXMn053440; Fri, 7 May 2004 10:39:34 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Fri May 7 11:05:50 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47I5nPH055255; Fri, 7 May 2004 11:05:50 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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: , 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 11:18:27 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47IIQ8S055856; Fri, 7 May 2004 11:18:26 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 11:24:33 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47IOWeO056236; Fri, 7 May 2004 11:24:32 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Fri May 7 11:42:43 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47Iggik057085; Fri, 7 May 2004 11:42:43 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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: , 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 12:05:01 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47J50pd058939; Fri, 7 May 2004 12:05:01 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Fri May 7 12:38:20 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47JcIw1061630; Fri, 7 May 2004 12:38:19 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Fri May 7 13:21:46 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47KLjik064809; Fri, 7 May 2004 13:21:46 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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: , 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 13:24:38 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i47KOaus064954; Fri, 7 May 2004 13:24:36 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Sun May 9 11:06:06 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i49I66hS008245; Sun, 9 May 2004 11:06:06 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Mon May 10 14:28:45 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ALSi90018397; Mon, 10 May 2004 14:28:45 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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" 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 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4ALSi90018397 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] 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. 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 Mon May 10 15:33:02 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4AMX0Ek021891; Mon, 10 May 2004 15:33:01 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Mon May 10 16:23:05 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ANN2PL025987; Mon, 10 May 2004 16:23:03 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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" 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 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4ANN2PL025987 Resend... this apparently got lost -----Original Message----- From: Charlie Kaufman 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 18:04:28 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4B14Qjl034133; Mon, 10 May 2004 18:04:27 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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 ipsec-admin@ietf.org Mon May 10 18:53:41 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4B1refi037318; Mon, 10 May 2004 18:53:40 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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

----------luhfwzolaiywfzilheva-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon May 10 19:52:08 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4B2q7xe043554; Mon, 10 May 2004 19:52:07 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) 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

	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

Click Here For Information