From ipsec-bounces@ietf.org Thu Jul 1 07:54:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61EsAWF051548; Thu, 1 Jul 2004 07:54:11 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg1qE-00022o-Ds; Thu, 01 Jul 2004 09:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bezva-00008g-S6 for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 13:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17516 for ; Mon, 28 Jun 2004 13:28:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BezvZ-0006QY-Tm for ipsec@ietf.org; Mon, 28 Jun 2004 13:28:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bezud-000695-00 for ipsec@ietf.org; Mon, 28 Jun 2004 13:27:23 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Beztc-0005bs-00 for ipsec@ietf.org; Mon, 28 Jun 2004 13:26:20 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2004 10:29:15 -0700 Received: from vilhuber-u30.cisco.com (vilhuber-u30.cisco.com [128.107.162.107]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5SHPmgJ022040; Mon, 28 Jun 2004 10:25:48 -0700 (PDT) Date: Mon, 28 Jun 2004 10:25:47 -0700 (PDT) From: Jan Vilhuber To: Bill Sommerfeld Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-Reply-To: <200406281222.i5SCM6rp002436@thunk.east.sun.com> Message-ID: References: <200406281222.i5SCM6rp002436@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Mailman-Approved-At: Thu, 01 Jul 2004 09:43:02 -0400 Cc: ipsec@ietf.org, Francis Dupont X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, 28 Jun 2004, Bill Sommerfeld wrote: > > - ROHC requires that the lower layer not reorder packets, whereas > > IPsec includes replay protection with a sequence number, it does *not* > > put packets back into their original order on receive. > > > > I disagree: IPsec does not change the order > > That's not at all clear to me. > > > (so it can't have a negative effect) and more, it helps the > > detection of reordering (by something else) and lost (i.e., it can > > have a positive effect). > > No, it seems perfectly clear. > > IPsec runs over IP, which is allowed to reorder packets. > > ROHC runs over link layers which are not allowed to reorder packets. > > Unless you have some impossible-to-obtain-in-general out-of-band > knowledge that an IPsec tunnel will only traverse links *and* routers > which never reorder packets, you cannot naively use ROHC over IPsec. > isn't that perfectly acceptable, though? There are situations where people KNOW exactly where their data is going. You can always build another layer AROUND the IPsec+ROHC layer to make sure packets get put back into some sort of order first, before handing them up the stack. That's not the job of the packet-definition, after all. We can provide a document that described how to put the two together, with adequate warnings, and leave the rest up to a follow-on document. I admit not being very ROHC savvy. I've been concentration on IPHC, or better yet, ECRTP, which CAN run over the internet at large just fine, and can be used to mitigate some of the packet expansion caused by ipsec itself. > An integrated IPsec - ROHC implementation could look at the IPsec > sequence number and insert its own reorder buffer, but such an > integration would not be as simple as defining an IP protocol number > for ROHC. > Agreed. But you could certainly build on that. BTW: I vote for an IP protocol number for IPHC in GENERAL (of which ROHC could/would be a subtype). jan > > - ROHC changes the encoding of header fields which are used for > > access control purposes by IPsec (inner tunnel headers, payload > > protocol, and transport-layer ports); a naive integration of ROHC > > inside IPsec would bypass IPsec's post-decryption access controls. > > > > I believe you refer to RFC 2401 section 5.2.1 steps 2 and 3. > > Obviously the decompression must be integrated, i.e., done just after > > decryption and before sanity post-decryption checks. BTW the checked > > fields are likely not transported in packets but taken from the > > decompression context. IMHO this is an implementation issue more > > than a real problem. > > It's an architectural issue. An integrated IPsec-ROHC means that the > ROHC would have to be inserted into the *middle* of IPsec processing, > between the policy enforcement part and the encryption part. > > Again, not so simple as merely defining an IP payload number for ROHC. > > - Bill > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 1 07:54:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61EsAtl051547; Thu, 1 Jul 2004 07:54:11 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg1qD-00022Q-Gj; Thu, 01 Jul 2004 09:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bezqo-0007eH-1v for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 13:23: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 NAA17164 for ; Mon, 28 Jun 2004 13:23:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bezqn-000516-3C for ipsec@ietf.org; Mon, 28 Jun 2004 13:23:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bezq1-0004mb-00 for ipsec@ietf.org; Mon, 28 Jun 2004 13:22:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BezpU-0004Xi-00 for ipsec@ietf.org; Mon, 28 Jun 2004 13:22:04 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2004 10:25:56 +0000 X-BrightmailFiltered: true Received: from vilhuber-u30.cisco.com (vilhuber-u30.cisco.com [128.107.162.107]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5SHLN4O016494; Mon, 28 Jun 2004 10:21:24 -0700 (PDT) Date: Mon, 28 Jun 2004 10:21:19 -0700 (PDT) From: Jan Vilhuber To: Francis Dupont Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-Reply-To: <200406260908.i5Q98mSj050201@givry.rennes.enst-bretagne.fr> Message-ID: References: <200406260908.i5Q98mSj050201@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Mailman-Approved-At: Thu, 01 Jul 2004 09:43:02 -0400 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sat, 26 Jun 2004, Francis Dupont wrote: > In your previous mail you wrote: > > Does any one know if such a mechanism was proposed ? > > => look at draft-vilhuber-hco{ip,esp}-xx.txt I bet these have long since expired, but I'd be happy to resubmit them (as individual submissions). When I first submitted these, there flood of responses and comments was astounding. I got one single email about it all (saying essentially "Cool.. I like it and have been thinking along similar lines"; I think that might even have been you, francis :). Is the IETF now interested in this thing? Previously, comments (in other working groups and other documents) were basically "Why would we want to do this?" (which to me seems obvious, of course). > This is also a goal of the MOBIKE WG. > BTW I believe we can do more in the ESP tunnel context than in the > standard one, for instance class more header fields as "static" > and reuse the SPI as a context number... I agree completely. There's also ways to get rid of checksums at the IPHC layer, and rely on the one from IPsec, allowing us to cut down even MORE on the size of the compressed header. > Can we continue offline? > I'm game if you want to include me on a private exchange. I still have the drafts, and we can use them as a start, if you like. jan > Thanks > > Francis.Dupont@enst-bretagne.fr > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 1 08:46:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i61FkStq055641; Thu, 1 Jul 2004 08:46:28 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg30k-0007wN-9d; Thu, 01 Jul 2004 10:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg27o-0003S1-Bx for ipsec@megatron.ietf.org; Thu, 01 Jul 2004 10:01: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 KAA28502 for ; Thu, 1 Jul 2004 10:01:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg27n-0006R7-He for ipsec@ietf.org; Thu, 01 Jul 2004 10:01:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg26r-00064J-00 for ipsec@ietf.org; Thu, 01 Jul 2004 10:00:17 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1Bg26S-0005hX-00 for ipsec@ietf.org; Thu, 01 Jul 2004 09:59:52 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i61DxKEP015963 for ; Thu, 1 Jul 2004 15:59:20 +0200 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i61DxKaC031980 for ; Thu, 1 Jul 2004 15:59:20 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Jul 2004 16:00:57 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532ABC1@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPsec WG (E-mail)" Date: Thu, 1 Jul 2004 16:00:09 +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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] Opaque and any in selectors of RFC2401bis 14 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On page 21, 4.4.1 it is stated, that for SPD ANY includes OPAQUE. On Page 34 of 4.4.2 for SAD, it seems to me that ANY does not include OPAQUE as e.g protocols has two ports Value in Triggering Resulting SAD Selector SPD Entry PFP Packet Entry -------- ---------------- --- ------------ -------------- loc port list of ranges 0 no src port discard packet or ANY OPAQUE 0 not avail. OPAQUE does this mean that for generation of SAD selector from SPD selector now ANY does not include OPAQUE ? or should the table be modified the following way ? Value in Triggering Resulting SAD Selector SPD Entry PFP Packet Entry -------- ---------------- --- ------------ -------------- loc port list of ranges 0 no src port discard packet ANY 0 no src port OPAQUE OPAQUE 0 not avail. OPAQUE Thanks in advance Peter _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 1 23:27:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i626R4v4052601; Thu, 1 Jul 2004 23:27:05 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgHRJ-0004Ub-JJ; Fri, 02 Jul 2004 02:22:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgHLL-0000Ux-5J for ipsec@megatron.ietf.org; Fri, 02 Jul 2004 02:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07967 for ; Fri, 2 Jul 2004 02:16:11 -0400 (EDT) From: wprice@cyphers.net Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgHLG-00030c-Fm for ipsec@ietf.org; Fri, 02 Jul 2004 02:16:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgHKK-0002eL-00 for ipsec@ietf.org; Fri, 02 Jul 2004 02:15:13 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BgHJa-0002I7-00 for ipsec@ietf.org; Fri, 02 Jul 2004 02:14:26 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i626Brg22758 for ; Fri, 2 Jul 2004 02:11:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i626BjBb027016 for ; Fri, 2 Jul 2004 02:11:45 -0400 (EDT) Message-Id: <200407020611.i626BjBb027016@nutshell.tislabs.com> Received: from unknown(211.87.231.104) by nutshell.tislabs.com via csmap (V6.0) id srcAAAG6aWN0; Fri, 2 Jul 04 02:11:35 -0400 To: ipsec@lists.tislabs.com Date: Fri, 2 Jul 2004 14:05:29 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="64505753" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=2.60 Cc: Subject: [Ipsec] stolen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --64505753 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit information about you --64505753 Content-Type: text/html; name="concert.zip.htm" Content-Disposition: attachment; filename="concert.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

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

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

--64505753 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --64505753-- From ipsec-bounces@ietf.org Fri Jul 2 02:47:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i629l9HT027080; Fri, 2 Jul 2004 02:47:10 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgKPp-0005cs-EM; Fri, 02 Jul 2004 05:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgK8W-0005yz-70 for ipsec@megatron.ietf.org; Fri, 02 Jul 2004 05:15: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 FAA19339 for ; Fri, 2 Jul 2004 05:15:09 -0400 (EDT) From: mundy@tislabs.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgK8T-00048h-RV for ipsec@ietf.org; Fri, 02 Jul 2004 05:15:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgK7c-0003nN-00 for ipsec@ietf.org; Fri, 02 Jul 2004 05:14:17 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BgK6s-0003Ri-00 for ipsec@ietf.org; Fri, 02 Jul 2004 05:13:30 -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 i629Asg14646 for ; Fri, 2 Jul 2004 05:10:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i629AlYT026275 for ; Fri, 2 Jul 2004 05:10:47 -0400 (EDT) Message-Id: <200407020910.i629AlYT026275@nutshell.tislabs.com> Received: from unknown(218.17.85.118) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQQaasZ; Fri, 2 Jul 04 05:10:42 -0400 To: ipsec@lists.tislabs.com Date: Fri, 2 Jul 2004 17:13:35 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" 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=3.9 required=5.0 tests=HTML_20_30, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Cc: Subject: [Ipsec] Re: here X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Your document is attached to this mail. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="details_ipsec.doc .scr.htm" Content-Disposition: attachment; filename="details_ipsec.doc .scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: details_ipsec.doc .scr
Virus name: W32/Netsky.p@MM

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

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Fri Jul 2 08:56:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Fug21065317; Fri, 2 Jul 2004 08:56:43 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgQ7K-0007vg-BJ; Fri, 02 Jul 2004 11:38:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgPve-0000xx-9i for ipsec@megatron.ietf.org; Fri, 02 Jul 2004 11:26: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 LAA13031 for ; Fri, 2 Jul 2004 11:26: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 1BgPvd-0001ja-Fg for ipsec@ietf.org; Fri, 02 Jul 2004 11:26:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgPue-0001Oz-00 for ipsec@ietf.org; Fri, 02 Jul 2004 11:25:17 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BgPtf-0000o1-00 for ipsec@ietf.org; Fri, 02 Jul 2004 11:24:15 -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 i62FNJ7Z025585; Fri, 2 Jul 2004 11:23:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <66CE949D18BCB249ABE8D9AF48C4F1CE2D49A7@helios.clb.tcfr.thales> References: <66CE949D18BCB249ABE8D9AF48C4F1CE2D49A7@helios.clb.tcfr.thales> Date: Fri, 2 Jul 2004 10:15:19 -0400 To: Francois.PAUL@fr.thalesgroup.com From: Stephen Kent Subject: RE: [Ipsec] Layer 2 processing inside IPsec 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 Cc: ipsec@ietf.org, sommerfeld@east.sun.com, Francis.Dupont@enst-bretagne.fr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:10 PM +0200 6/30/04, Francois.PAUL@fr.thalesgroup.com wrote: >I summarize hereafter the main points that arise from the different messages >posted to this list : > - Combining ROHC (or whichever generic compression frameworks suits) and >IPsec in an efficient way leads to an integration of ROHC in the middle of >IPsec. From the IPsec framework point of view, this could take the form ESP >used in tunnel mode, but with a specific "next header" value different from >"IP", in order for the policy enforcement processing to take place just >after decryption and decompression, along the lines of what Jan Vilhuber >proposed. tunnel mode requires that the next header be IP (v4 or v6) because that header is used for the access control checks. So I don't understand your description above. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 2 09:47:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Gl4tD069188; Fri, 2 Jul 2004 09:47:05 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgR5Q-0005F8-6F; Fri, 02 Jul 2004 12:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgQv5-0007A6-A7 for ipsec@megatron.ietf.org; Fri, 02 Jul 2004 12:29:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18175 for ; Fri, 2 Jul 2004 12:29:44 -0400 (EDT) From: Francois.PAUL@fr.thalesgroup.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgQv4-0000hn-DF for ipsec@ietf.org; Fri, 02 Jul 2004 12:29:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgQu6-0000KF-00 for ipsec@ietf.org; Fri, 02 Jul 2004 12:28:46 -0400 Received: from gwout.thalesgroup.com ([195.101.39.227]) by ietf-mx with esmtp (Exim 4.12) id 1BgQsy-0007OW-00 for ipsec@ietf.org; Fri, 02 Jul 2004 12:27:36 -0400 Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 40D9AF1C0025A376 for ipsec@ietf.org; Fri, 2 Jul 2004 18:26:37 +0200 Received: from hiplex.tsbh.thales ([10.33.19.4]) by thalescan with InterScan Messaging Security Suite; Fri, 02 Jul 2004 18:26:04 +0200 Received: from hiplex.tsbh.thales (10.33.21.5) by hiplex.tsbh.thales (NPlex 6.5.026) id 40C82B1F000CA184 for ipsec@ietf.org; Fri, 2 Jul 2004 18:26:04 +0200 Received: from complex.tcfr.thales ([202.3.3.26]) by hiplex with InterScan Messaging Security Suite; Fri, 02 Jul 2004 18:26:04 +0200 Received: from complex.tcfr.thales (202.3.3.26) by complex.tcfr.thales (NPlex 6.5.026) id 40E58488000003E4 for ipsec@ietf.org; Fri, 2 Jul 2004 18:24:44 +0200 Received: from NODALNET.clb.tcfr.thales ([146.11.5.4]) by complex with InterScan Messaging Security Suite; Fri, 02 Jul 2004 18:24:43 +0200 Received: by NODALNET.clb.tcfr.thales with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Jul 2004 18:26:03 +0200 Message-ID: <66CE949D18BCB249ABE8D9AF48C4F1CE2D49AD@helios.clb.tcfr.thales> To: kent@bbn.com Subject: RE: [Ipsec] Layer 2 processing inside IPsec Date: Fri, 2 Jul 2004 18:26:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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, NO_REAL_NAME autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is the reason why it is proposed to insert decompression *between* decryption and policy enforcement. Once the encrypted payload is decrypted, if the "next header" field shows that it is a ROHC-compressed packet, the appropriate decompressor is applied, which produces a regular IPv4 or IPv6 packet header. Then, the classical IPsec access control checks are applied. This is described in details in Jan Vilhuber's proposal, though the present draft invokes compression schemes (not so) different from ROHC. F. Paul -----Message d'origine----- De : Stephen Kent [mailto:kent@bbn.com] Envoye : vendredi 2 juillet 2004 16:15 A : Francois.PAUL@fr.thalesgroup.com Cc : Francis.Dupont@enst-bretagne.fr; sommerfeld@east.sun.com; ipsec@ietf.org Objet : RE: [Ipsec] Layer 2 processing inside IPsec At 8:10 PM +0200 6/30/04, Francois.PAUL@fr.thalesgroup.com wrote: >I summarize hereafter the main points that arise from the different messages >posted to this list : > - Combining ROHC (or whichever generic compression frameworks suits) and >IPsec in an efficient way leads to an integration of ROHC in the middle of >IPsec. From the IPsec framework point of view, this could take the form ESP >used in tunnel mode, but with a specific "next header" value different from >"IP", in order for the policy enforcement processing to take place just >after decryption and decompression, along the lines of what Jan Vilhuber >proposed. tunnel mode requires that the next header be IP (v4 or v6) because that header is used for the access control checks. So I don't understand your description above. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 2 11:25:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62IPcgu077489; Fri, 2 Jul 2004 11:25:39 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgSdK-0000Ym-SX; Fri, 02 Jul 2004 14:19:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgSCF-00035g-NM for ipsec@megatron.ietf.org; Fri, 02 Jul 2004 13:51:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23112 for ; Fri, 2 Jul 2004 13:51:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgSCE-00050j-Nm for ipsec@ietf.org; Fri, 02 Jul 2004 13:51:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgSBF-0004g7-00 for ipsec@ietf.org; Fri, 02 Jul 2004 13:50:34 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BgSAJ-00041D-00 for ipsec@ietf.org; Fri, 02 Jul 2004 13:49:35 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i62Hn27Z003360; Fri, 2 Jul 2004 13:49:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <66CE949D18BCB249ABE8D9AF48C4F1CE2D49AD@helios.clb.tcfr.thales> References: <66CE949D18BCB249ABE8D9AF48C4F1CE2D49AD@helios.clb.tcfr.thales> Date: Fri, 2 Jul 2004 13:41:18 -0400 To: Francois.PAUL@fr.thalesgroup.com From: Stephen Kent Subject: RE: [Ipsec] Layer 2 processing inside IPsec 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 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 6:26 PM +0200 7/2/04, Francois.PAUL@fr.thalesgroup.com wrote: >This is the reason why it is proposed to insert decompression *between* >decryption and policy enforcement. Once the encrypted payload is decrypted, >if the "next header" field shows that it is a ROHC-compressed packet, the >appropriate decompressor is applied, which produces a regular IPv4 or IPv6 >packet header. Then, the classical IPsec access control checks are applied. > >This is described in details in Jan Vilhuber's proposal, though the present >draft invokes compression schemes (not so) different from ROHC. > >F. Paul > Thanks for the clarification. it was just the choice of words that made it confusing to me. Look at the new processing model in 2401bis, and see how you would describe the processing in that context, to make sure this is consistent with that model. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 2 11:30:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i62IUdbJ077849; Fri, 2 Jul 2004 11:30:42 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgSdd-0000g8-Dz; Fri, 02 Jul 2004 14:19:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgSMU-0007u8-43 for ipsec@megatron.ietf.org; Fri, 02 Jul 2004 14:02:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23538 for ; Fri, 2 Jul 2004 14:02: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 1BgSMT-0000RQ-2L for ipsec@ietf.org; Fri, 02 Jul 2004 14:02:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgSJx-0007bI-00 for ipsec@ietf.org; Fri, 02 Jul 2004 13:59:33 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BgSIw-0006ud-00 for ipsec@ietf.org; Fri, 02 Jul 2004 13:58:30 -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 i62Hvb7X003772; Fri, 2 Jul 2004 13:57:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3FFBC907DD03A34CA4410C5C745DEB1201B731B0@wnimail.WoodsideNet.Com> References: <3FFBC907DD03A34CA4410C5C745DEB1201B731B0@wnimail.WoodsideNet.Com> Date: Fri, 2 Jul 2004 13:52:03 -0400 To: "Paul Lambert" From: Stephen Kent Subject: RE: [Ipsec] Layer 2 processing inside IPsec 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 Cc: ipsec@ietf.org, sommerfeld@east.sun.com, Francis.Dupont@enst-bretagne.fr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:33 AM -0700 7/2/04, Paul Lambert wrote: > >tunnel mode requires that the next header be IP (v4 or v6) > >Requireing the next header to be IP is just one type of access >policy. There is no reason that an access policy could not allow >other protocols and process/filter them accordingly. > >Paul > >- There is a requirement for an IPsec TUNNEL to have an inner IP header, because of the need to forward the inner packet based on that header, and because our access control checks are defined relative to IP and next layer headers. if there is no need to forward the packet based on an inner IP header, then transport mode is used, and the access controls are applied to the outer header. Steeve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jul 3 12:53:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i63JreSM034801; Sat, 3 Jul 2004 12:53:41 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bgq0Z-00011d-5z; Sat, 03 Jul 2004 15:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgpU4-0003dB-0E for ipsec@megatron.ietf.org; Sat, 03 Jul 2004 14:43:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08271 for ; Sat, 3 Jul 2004 13:36:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgoR9-0005OX-37 for ipsec@ietf.org; Sat, 03 Jul 2004 13:36:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgoQD-00057s-00 for ipsec@ietf.org; Sat, 03 Jul 2004 13:35:29 -0400 Received: from bay8-f97.bay8.hotmail.com ([64.4.27.97] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BgoPd-0004q2-00 for ipsec@ietf.org; Sat, 03 Jul 2004 13:34:53 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 3 Jul 2004 10:34:22 -0700 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Sat, 03 Jul 2004 17:34:22 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: ipsec@ietf.org Date: Sat, 03 Jul 2004 17:34:22 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jul 2004 17:34:22.0297 (UTC) FILETIME=[FA387490:01C46123] 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 Subject: [Ipsec] RFC 3715 / IPsec NAT Compatibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Folks, Quick question about RFC 3715 - on page 4 (c) the RFC mentions incompatibility between IKE address identifiers and NAT. Would I be right in saying that this incompatibility occurs only in transport mode when using IP addresses as phase 1 identifiers, and when the source address of ISAKMP packets is checked against the traffic selectors carried as identifiers in phase 2 ?? Or have I completely missed the point :) Many thanks in advance. _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 4 08:26:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i64FQeEP018678; Sun, 4 Jul 2004 08:26:40 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bh8Mm-0003pF-N9; Sun, 04 Jul 2004 10:53:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bh87a-0002MN-Kg for ipsec@megatron.ietf.org; Sun, 04 Jul 2004 10:37:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16630 for ; Sun, 4 Jul 2004 10:37:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bh87K-0004Vo-Bp for ipsec@ietf.org; Sun, 04 Jul 2004 10:37:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bh86N-0004IE-00 for ipsec@ietf.org; Sun, 04 Jul 2004 10:36:19 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bh85c-00043c-00 for ipsec@ietf.org; Sun, 04 Jul 2004 10:35:32 -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 i64EWhg20168 for ; Sun, 4 Jul 2004 10:32:44 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i64EWeCE006249 for ; Sun, 4 Jul 2004 10:32:40 -0400 (EDT) Received: from unknown(203.197.150.77) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhcaajm; Sun, 4 Jul 04 10:32:30 -0400 Date: Sun, 04 Jul 2004 20:11:12 +0530 To: "Ipsec" From: "Scott" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------okbibbjocqtdsmuxfuph" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Notification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------okbibbjocqtdsmuxfuph Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------okbibbjocqtdsmuxfuph Content-Type: text/html; name="the_message.com.htm" Content-Disposition: attachment; filename="the_message.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: the_message.com
Virus name: W32/Bagle.aa@MM

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

----------okbibbjocqtdsmuxfuph Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------okbibbjocqtdsmuxfuph-- From ipsec-bounces@ietf.org Mon Jul 5 08:19:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i65FJ10N035557; Mon, 5 Jul 2004 08:19:01 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhUiU-00023z-P5; Mon, 05 Jul 2004 10:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhUX3-0000h5-WA for ipsec@megatron.ietf.org; Mon, 05 Jul 2004 10:33:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00479 for ; Mon, 5 Jul 2004 10:33:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhUWy-000125-2D for ipsec@ietf.org; Mon, 05 Jul 2004 10:33:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhUV0-0000Ix-00 for ipsec@ietf.org; Mon, 05 Jul 2004 10:31:15 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BhUTH-0007ez-00 for ipsec@ietf.org; Mon, 05 Jul 2004 10:29:27 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i65EQlg17733 for ; Mon, 5 Jul 2004 10:26:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i65EQjRR001193 for ; Mon, 5 Jul 2004 10:26:45 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAqWa4sc; Mon, 5 Jul 04 10:26:37 -0400 Date: Mon, 05 Jul 2004 15:35:48 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pbmylounlhsvddlrwcwp" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] RE: Text message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------pbmylounlhsvddlrwcwp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------pbmylounlhsvddlrwcwp Content-Type: text/html; name="Alive_condom.vbs.htm" Content-Disposition: attachment; filename="Alive_condom.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: Alive_condom.vbs
Virus name: W32/Bagle.aa@MM!vbs

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

----------pbmylounlhsvddlrwcwp Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------pbmylounlhsvddlrwcwp-- From ipsec-bounces@ietf.org Tue Jul 6 02:24:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i669OMVm097628; Tue, 6 Jul 2004 02:24:22 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhlfv-0005QU-1V; Tue, 06 Jul 2004 04:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhlQB-0004Ef-QP for ipsec@megatron.ietf.org; Tue, 06 Jul 2004 04:35: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 EAA28835 for ; Tue, 6 Jul 2004 04:35: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 1BhlQ4-0004ij-De for ipsec@ietf.org; Tue, 06 Jul 2004 04:35:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhlPE-0004Pm-00 for ipsec@ietf.org; Tue, 06 Jul 2004 04:34:24 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BhlOK-00045Q-00 for ipsec@ietf.org; Tue, 06 Jul 2004 04:33: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 i668Uig28315 for ; Tue, 6 Jul 2004 04:30:46 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i668Ufqp002761 for ; Tue, 6 Jul 2004 04:30:41 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAj3aiwf; Tue, 6 Jul 04 04:30:38 -0400 Date: Tue, 06 Jul 2004 09:39:47 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------weuwkdvqmlwkfellargt" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Re: Yahoo! X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------weuwkdvqmlwkfellargt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------weuwkdvqmlwkfellargt Content-Type: text/html; name="Document.exe.htm" Content-Disposition: attachment; filename="Document.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Document.exe
Virus name: W32/Bagle.aa@MM

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

----------weuwkdvqmlwkfellargt Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------weuwkdvqmlwkfellargt-- From ipsec-bounces@ietf.org Tue Jul 6 02:33:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i669XDVD000848; Tue, 6 Jul 2004 02:33:14 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhlno-00062P-59; Tue, 06 Jul 2004 04:59:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhleZ-0005JX-Qm for ipsec@megatron.ietf.org; Tue, 06 Jul 2004 04:50:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29183 for ; Tue, 6 Jul 2004 04:50:08 -0400 (EDT) From: hugh@mimosa.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhleS-0001TH-BG for ipsec@ietf.org; Tue, 06 Jul 2004 04:50:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bhld2-0000rS-00 for ipsec@ietf.org; Tue, 06 Jul 2004 04:48:41 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bhlc7-0000UZ-00 for ipsec@ietf.org; Tue, 06 Jul 2004 04:47:43 -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 1BhlQQ-0008LN-Hx for ipsec@ietf.org; Tue, 06 Jul 2004 04:35:38 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i668Wtg28674 for ; Tue, 6 Jul 2004 04:32:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i668WrXP003119 for ; Tue, 6 Jul 2004 04:32:53 -0400 (EDT) Message-Id: <200407060832.i668WrXP003119@nutshell.tislabs.com> Received: from unknown(211.87.231.104) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHQayeg; Tue, 6 Jul 04 04:32:48 -0400 To: ipsec@lists.tislabs.com Date: Tue, 6 Jul 2004 16:26:38 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="76743742" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=2.60 Cc: Subject: [Ipsec] unknown X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --76743742 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit from the chatter --76743742 Content-Type: text/html; name="final.zip.htm" Content-Disposition: attachment; filename="final.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

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

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

--76743742 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --76743742-- From ipsec-bounces@ietf.org Tue Jul 6 22:16:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i675G98O072501; Tue, 6 Jul 2004 22:16:10 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi49I-0004I1-EB; Wed, 07 Jul 2004 00:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi3oL-0006G2-JR for ipsec@megatron.ietf.org; Wed, 07 Jul 2004 00:13:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20163 for ; Wed, 7 Jul 2004 00:13:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bi3oE-0001db-OQ for ipsec@ietf.org; Wed, 07 Jul 2004 00:13:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi3nM-0001Gu-00 for ipsec@ietf.org; Wed, 07 Jul 2004 00:12:33 -0400 Received: from ip-66-80-10-147.dsl.sca.megapath.net ([66.80.10.147] helo=brahma.intotoind.com) by ietf-mx with esmtp (Exim 4.12) id 1Bi3mS-0000tq-00 for ipsec@ietf.org; Wed, 07 Jul 2004 00:11:36 -0400 Received: from jyothi.intoto.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i674BYD4003724 for ; Wed, 7 Jul 2004 09:41:34 +0530 Message-Id: <5.1.0.14.0.20040707084749.00a723c0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 07 Jul 2004 09:30:02 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 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] IKEv2 with RFC2401 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, If we use IKEv2 with RFC2401 implementation and not using RFC2401bis, there wont be any support for following features: Multiple ranges, port range, ICMP types, IPV6 I would like to know if there are any other complications if we use IKEv2 with RFC 2401 implementation. Many thanks in advance, Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 6 22:18:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i675Id2i073531; Tue, 6 Jul 2004 22:18:41 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi4LJ-0007Q8-FJ; Wed, 07 Jul 2004 00:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi42k-0001R1-SV for ipsec@megatron.ietf.org; Wed, 07 Jul 2004 00:28:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21389 for ; Wed, 7 Jul 2004 00:28:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bi42e-0007IA-0X for ipsec@ietf.org; Wed, 07 Jul 2004 00:28:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi41l-0006vf-00 for ipsec@ietf.org; Wed, 07 Jul 2004 00:27:26 -0400 Received: from ip-66-80-10-147.dsl.sca.megapath.net ([66.80.10.147] helo=brahma.intotoind.com) by ietf-mx with esmtp (Exim 4.12) id 1Bi40z-0006XT-00 for ipsec@ietf.org; Wed, 07 Jul 2004 00:26:37 -0400 Received: from jyothi.intoto.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i674QaYO006607 for ; Wed, 7 Jul 2004 09:56:36 +0530 Message-Id: <5.1.0.14.0.20040707093110.00a3ca30@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 07 Jul 2004 10:00:10 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL, HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] Rekeying of child SA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0908382567==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0908382567== Content-Type: multipart/alternative; boundary="=====================_85249274==_.ALT" --=====================_85249274==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, In draft-ietf-ipsec-ikev2-14.txt, section 2.8 Rekeying, it contains the following information: To allow for minimal IPsec implementations, the ability to rekey SAs without restarting the entire IKE_SA is optional. An implementation MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA has expired or is about to expire and rekeying attempts using the mechanisms described here fail, an implementation MUST close the IKE_SA and any associated CHILD_SAs and then MAY start new ones. Implementations SHOULD support in place rekeying of SAs, since doing so offers better performance and is likely to reduce the number of packets lost during the transition. May I know the reason behind this. Why the CREATE_CHAILD_SA exchange made as optional. There may be some issues regarding this. Suppose, I configured PFS in IPSEC as DH MODP2048, and DH group in IKE as MODP1536. In IKE_SA_INIT exchange, only one KE payload is negotiated for shared secret used in IKE (MODP1536) to generate the key material. May I know in detail how can I use PFS configured in IPSEC by not using CREATE_CHILD_SA exchange?? My understanding is that if we configure the PFS in IPSEC, we create IKE SAs using IKE_SA_INIT exchange and we create CHILD SAs using CREATE_CHILD_SA exchange. I think, what I understood might be wrong. Please clarify. Many thanks in advance, Jyothi --=====================_85249274==_.ALT Content-Type: text/html; charset="us-ascii" Hi all,

In draft-ietf-ipsec-ikev2-14.txt, section 2.8 Rekeying, it contains the following information:

To allow for minimal IPsec implementations, the ability to rekey SAs
   without restarting the entire IKE_SA is optional. An implementation
   MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA
   has expired or is about to expire and rekeying attempts using the
   mechanisms described here fail, an implementation MUST close the
   IKE_SA and any associated CHILD_SAs and then MAY start new ones.
   Implementations SHOULD support in place rekeying of SAs, since doing
   so offers better performance and is likely to reduce the number of
   packets lost during the transition.

May I know the reason behind this. Why the CREATE_CHAILD_SA exchange made as optional.

There may be some issues regarding this.

Suppose, I configured PFS in IPSEC as DH MODP2048, and DH group in IKE as MODP1536.

In IKE_SA_INIT exchange, only one KE payload is negotiated for shared secret used in IKE (MODP1536) to generate the key material.

May I know in detail how can I use PFS configured in IPSEC by not using CREATE_CHILD_SA exchange??

My understanding is that if we configure the PFS in IPSEC, we create IKE SAs using IKE_SA_INIT exchange and we create CHILD SAs using CREATE_CHILD_SA exchange.

I think, what I understood might be wrong. Please clarify.

Many thanks in advance,
Jyothi



 --=====================_85249274==_.ALT-- --===============0908382567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0908382567==-- From ipsec-bounces@ietf.org Wed Jul 7 00:06:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6776cnD024168; Wed, 7 Jul 2004 00:06:39 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi5q3-00083J-H6; Wed, 07 Jul 2004 02:23:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bi5Tc-0005W5-U7 for ipsec@megatron.ietf.org; Wed, 07 Jul 2004 02:00: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 CAA26424 for ; Wed, 7 Jul 2004 02:00: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 1Bi5TV-0000iK-SB for ipsec@ietf.org; Wed, 07 Jul 2004 02:00:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bi5Sb-0000Ng-00 for ipsec@ietf.org; Wed, 07 Jul 2004 01:59:13 -0400 Received: from ip-66-80-10-147.dsl.sca.megapath.net ([66.80.10.147] helo=brahma.intotoind.com) by ietf-mx with esmtp (Exim 4.12) id 1Bi5Rs-000031-00 for ipsec@ietf.org; Wed, 07 Jul 2004 01:58:28 -0400 Received: from jyothi.intoto.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i675wRbA023348 for ; Wed, 7 Jul 2004 11:28:27 +0530 Message-Id: <5.1.0.14.0.20040707100014.00a45cf0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 07 Jul 2004 11:32:01 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] certificate encoding type in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0128008434==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0128008434== Content-Type: multipart/alternative; boundary="=====================_90760529==_.ALT" --=====================_90760529==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, In draft-ietf-ipsec-ikev2-14.txt, section 3.6 following certificate encoding types are defined: PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 Kerberos Token 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 Raw RSA Key 11 Hash and URL of X.509 certificate 12 Hash and URL of X.509 bundle 13 I would like to what is MUST in above defined types. In IKEv2, it is X.509 certificate-signature. I would also like to know what is cert bundle which is defined in page 58. Is it related to certificate chain?? How can we use certificate chains in IKEv2?? Many thanks in advance, Jyothi --=====================_90760529==_.ALT Content-Type: text/html; charset="us-ascii" Hi all,

In draft-ietf-ipsec-ikev2-14.txt, section 3.6 following certificate encoding types are defined:

           PKCS #7 wrapped X.509 certificate    1
           PGP Certificate                      2
           DNS Signed Key                       3
           X.509 Certificate - Signature        4
           Kerberos Token                       6
           Certificate Revocation List (CRL)    7
           Authority Revocation List (ARL)      8
           SPKI Certificate                     9
           X.509 Certificate - Attribute       10
           Raw RSA Key                         11
           Hash and URL of X.509 certificate   12
           Hash and URL of X.509 bundle        13

I would like to what is MUST in above defined types.
In IKEv2, it is X.509 certificate-signature.

I would also like to know what is cert bundle which is defined in page 58.
Is it related to certificate chain??

How can we use certificate chains in IKEv2??

Many thanks in advance,
Jyothi
 --=====================_90760529==_.ALT-- --===============0128008434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0128008434==-- From ipsec-bounces@ietf.org Wed Jul 7 10:53:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i67HrM1I044662; Wed, 7 Jul 2004 10:53:22 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiFwq-0003ht-6i; Wed, 07 Jul 2004 13:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiEqf-0000ET-IS for ipsec@megatron.ietf.org; Wed, 07 Jul 2004 12:00:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27516 for ; Wed, 7 Jul 2004 12:00:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiEqZ-00058c-Jw for ipsec@ietf.org; Wed, 07 Jul 2004 12:00:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiEpe-0004p0-00 for ipsec@ietf.org; Wed, 07 Jul 2004 11:59:38 -0400 Received: from wire.cs.nthu.edu.tw ([140.114.79.60]) by ietf-mx with esmtp (Exim 4.12) id 1BiEp1-0004Vu-00 for ipsec@ietf.org; Wed, 07 Jul 2004 11:59:00 -0400 Received: from wire.cs.nthu.edu.tw (localhost.localdomain [127.0.0.1]) by wire.cs.nthu.edu.tw (Postfix) with ESMTP id C2BDD17C42 for ; Thu, 8 Jul 2004 00:05:06 +0800 (CST) From: "ginno" To: ipsec@ietf.org Date: Thu, 8 Jul 2004 00:05:06 +0800 Message-Id: <20040707155850.M15353@wire.cs.nthu.edu.tw> X-Mailer: Open WebMail 2.20 20031014 X-OriginatingIP: 140.114.79.53 (ginno) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 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] How to install IPSec on Embedded linux ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear all, Does anyone have installed VPN and IPsec on Embedded linux successfully ? I want to install them on embedded linux, kernel 2.4.19-rmk6, but I can't find out any open embedded linux version of them. Please help me, thank you very much. cheers -- Open WebMail Project (http://openwebmail.org) _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 7 17:50:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i680oOqP075431; Wed, 7 Jul 2004 17:50:25 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiLAJ-0002uM-8a; Wed, 07 Jul 2004 18:45:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiJpr-00047V-Ke for ipsec@megatron.ietf.org; Wed, 07 Jul 2004 17:20: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 RAA17936 for ; Wed, 7 Jul 2004 17:20:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiJpl-0002Ne-1r for ipsec@ietf.org; Wed, 07 Jul 2004 17:20:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiJot-00023Z-00 for ipsec@ietf.org; Wed, 07 Jul 2004 17:19:12 -0400 Received: from mailgw1.technion.ac.il ([132.68.238.34]) by ietf-mx with esmtp (Exim 4.12) id 1BiJoD-0001ic-00; Wed, 07 Jul 2004 17:18:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw1.technion.ac.il (Postfix) with ESMTP id B8250FF986; Thu, 8 Jul 2004 00:18:28 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw1.technion.ac.il ([127.0.0.1]) by localhost (mailgw1.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03993-01-78; Thu, 8 Jul 2004 00:18:28 +0300 (IDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw1.technion.ac.il (Postfix) with ESMTP id A8235FF898; Thu, 8 Jul 2004 00:18:23 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id i67LKnCR005490; Thu, 8 Jul 2004 00:20:49 +0300 (IDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id i67LKhFD005487; Thu, 8 Jul 2004 00:20:49 +0300 (IDT) Date: Thu, 8 Jul 2004 00:20:43 +0300 (IDT) From: Hugo Krawczyk To: iesg@ietf.org Subject: Re: [Ipsec] Last Call: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' to Proposed Standard In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, Donald.Eastlake@Motorola.com, IETF-Announce X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Draft draft-ietf-ipsec-esp-ah-algorithms-01.txt specifies HMAC-MD5 as MAY (in the list of authentication algorithms). Given that 8 years after the invention of HMAC and 8 years after Dobbertin's attacks on MD5 there is no single piece of evidence (big or small) against the use of HMAC-MD5, and given that HMAC-MD5 is close to twice the speed of HMAC-SHA1, then I suggest to upgrade HMAC-MD5 to SHOULD (it is good to make it available for applications that need the speed, especially in authentication-only configurations (are there any?) Just a suggestion. Feel free to ignore. Hugo On Wed, 23 Jun 2004, The IESG wrote: > The IESG has received a request from the IP Security Protocol WG to consider > the following document: > > - 'Cryptographic Algorithm Implementation Requirements For ESP And AH ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action.Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-07-07. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 7 20:59:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i683xLRY090907; Wed, 7 Jul 2004 20:59:22 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiO9R-0002tH-DY; Wed, 07 Jul 2004 21:56:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiMMC-0003sY-Nf for ipsec@megatron.ietf.org; Wed, 07 Jul 2004 20:01: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 UAA29128 for ; Wed, 7 Jul 2004 20:01:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiMM6-0001Eg-6A for ipsec@ietf.org; Wed, 07 Jul 2004 20:01:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiML3-0000rA-00 for ipsec@ietf.org; Wed, 07 Jul 2004 20:00:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BiMJt-0000S0-00 for ipsec@ietf.org; Wed, 07 Jul 2004 19:59:21 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2004 17:05:10 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i67Nwn4N003369; Wed, 7 Jul 2004 16:58:50 -0700 (PDT) Received: from [171.71.49.148] (dhcp-171-71-49-148.cisco.com [171.71.49.148]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVD92332; Wed, 7 Jul 2004 16:57:39 -0700 (PDT) Message-ID: <40EC8E39.3080905@cisco.com> Date: Wed, 07 Jul 2004 16:58:49 -0700 From: Kevin Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Subject: Re: [Ipsec] RFC 3715 / IPsec NAT Compatibility References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Bob Arthurs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Does IKEv2 have similar limitation? I.e. IP address shouldn't be used as the identifier when there is NAT. BTW, why such limitation while IKE has the authentication in place? Thanks. Kevin Li ================== Quote from RFC3715/page 4/(c) c) Incompatibility between IKE address identifiers and NAT. Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets. ... Bob Arthurs wrote: > Hi Folks, > > Quick question about RFC 3715 - on page 4 (c) the RFC mentions > incompatibility between IKE address identifiers and NAT. > > Would I be right in saying that this incompatibility occurs only in > transport mode when using IP addresses as phase 1 identifiers, and > when the source address of ISAKMP packets is checked against the > traffic selectors carried as identifiers in phase 2 ?? Or have I > completely missed the point :) > > Many thanks in advance. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 7 21:51:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i684pCew095037; Wed, 7 Jul 2004 21:51:13 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiPNh-00034t-5g; Wed, 07 Jul 2004 23:15:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiNnj-0005bs-Oi for ipsec@megatron.ietf.org; Wed, 07 Jul 2004 21:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03380 for ; Wed, 7 Jul 2004 21:34: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 1BiNnd-0007Pr-4V for ipsec@ietf.org; Wed, 07 Jul 2004 21:34:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiNmi-00076U-00 for ipsec@ietf.org; Wed, 07 Jul 2004 21:33:13 -0400 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BiNlr-0006e4-00; Wed, 07 Jul 2004 21:32:19 -0400 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id 6FF8166403C; Wed, 7 Jul 2004 21:31:50 -0400 (EDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 6C1781974C6; Wed, 7 Jul 2004 21:31:18 -0400 (EDT) Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i681Vn417485; Wed, 7 Jul 2004 21:31:49 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 8705E1AE89; Wed, 7 Jul 2004 21:31:49 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Hugo Krawczyk Subject: Re: [Ipsec] Last Call: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' to Proposed Standard In-Reply-To: Your message of "Thu, 08 Jul 2004 00:20:43 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jul 2004 21:31:49 -0400 Message-Id: <20040708013149.8705E1AE89@berkshire.research.att.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org, Donald.Eastlake@Motorola.com, iesg@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In message , Hugo Krawczyk writes: >Draft draft-ietf-ipsec-esp-ah-algorithms-01.txt >specifies HMAC-MD5 as MAY (in the list of authentication algorithms). > >Given that 8 years after the invention of HMAC and 8 years after >Dobbertin's attacks on MD5 there is no single piece of evidence (big or >small) against the use of HMAC-MD5, and given that HMAC-MD5 is close to >twice the speed of HMAC-SHA1, then I suggest to upgrade HMAC-MD5 to SHOULD >(it is good to make it available for applications that need the speed, >especially in authentication-only configurations (are there any?) > >Just a suggestion. Feel free to ignore. > What did the WG say if/when you raised this during WG Last Call? --Steve Bellovin, http://www.research.att.com/~smb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 7 23:53:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i686r5SQ045166; Wed, 7 Jul 2004 23:53:06 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiRlC-0000QC-CX; Thu, 08 Jul 2004 01:47:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiQkc-00084I-J9 for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 00:43: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 AAA12176 for ; Thu, 8 Jul 2004 00:43:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiQkV-00071q-Nc for ipsec@ietf.org; Thu, 08 Jul 2004 00:43:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiQjd-0006ig-00 for ipsec@ietf.org; Thu, 08 Jul 2004 00:42:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BiQj1-0006MH-00 for ipsec@ietf.org; Thu, 08 Jul 2004 00:41:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2004 21:47:27 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i684f44N015696; Wed, 7 Jul 2004 21:41:04 -0700 (PDT) Received: from [10.32.244.26] (stealth-10-32-244-26.cisco.com [10.32.244.26]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVE06574; Wed, 7 Jul 2004 21:39:52 -0700 (PDT) Message-ID: <40ECD0A1.9050804@cisco.com> Date: Wed, 07 Jul 2004 21:42:09 -0700 From: Geoffrey Huang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Li Subject: Re: [Ipsec] RFC 3715 / IPsec NAT Compatibility References: <40EC8E39.3080905@cisco.com> In-Reply-To: <40EC8E39.3080905@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Bob Arthurs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Kevin Li wrote: > Hi, > > Does IKEv2 have similar limitation? > I.e. IP address shouldn't be used as the identifier when there is NAT. The problem is you won't always know there's a NAT between you and the peer. > BTW, why such limitation while IKE has the authentication in place? IKE ties some authentication material to an identity. In some cases, the identity can be an IP address. The problem occurs when the address changes unexpectedly (as is the case when NAT is involved). -g > Thanks. > > Kevin Li > > ================== Quote from RFC3715/page 4/(c) > > c) Incompatibility between IKE address identifiers and NAT. Where IP > addresses are used as identifiers in Internet Key Exchange > Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the > IP source or destination addresses by NATs or reverse NATs will > result in a mismatch between the identifiers and the addresses in > the IP header. As described in [RFC2409], IKE implementations are > required to discard such packets. > ... > > Bob Arthurs wrote: > >> Hi Folks, >> >> Quick question about RFC 3715 - on page 4 (c) the RFC mentions >> incompatibility between IKE address identifiers and NAT. >> >> Would I be right in saying that this incompatibility occurs only in >> transport mode when using IP addresses as phase 1 identifiers, and >> when the source address of ISAKMP packets is checked against the >> traffic selectors carried as identifiers in phase 2 ?? Or have I >> completely missed the point :) >> >> Many thanks in advance. > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 8 05:35:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68CYxTU036757; Thu, 8 Jul 2004 05:35:00 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiX8S-0001Mz-22; Thu, 08 Jul 2004 07:32:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiWXs-0006lt-B3 for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 06:54: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 GAA12724 for ; Thu, 8 Jul 2004 06:54:20 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiWXk-0007Hp-SD for ipsec@ietf.org; Thu, 08 Jul 2004 06:54:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiWWq-0006zR-00 for ipsec@ietf.org; Thu, 08 Jul 2004 06:53:25 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BiWWH-0006gw-00 for ipsec@ietf.org; Thu, 08 Jul 2004 06:52:50 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i68AqJA16571; Thu, 8 Jul 2004 13:52:19 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 13:52:14 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i68AqEfL002363; Thu, 8 Jul 2004 13:52:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 005FGYSX; Thu, 08 Jul 2004 13:52:12 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i68AqBn20313; Thu, 8 Jul 2004 13:52:11 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 13:52:09 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ipsec] RFC 3715 / IPsec NAT Compatibility Date: Thu, 8 Jul 2004 13:52:08 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C135@esebe023.ntc.nokia.com> Thread-Topic: [Ipsec] RFC 3715 / IPsec NAT Compatibility Thread-Index: AcRkpMzqn3EIUWUPToqDuKenmYcsrgAMPHwQ To: , X-OriginalArrivalTime: 08 Jul 2004 10:52:09.0412 (UTC) FILETIME=[9DF73040:01C464D9] 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, NO_REAL_NAME autolearn=no version=2.60 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i68CYxTU036757 Hi, I cannot find anything in draft-ietf-ipsec-ikev14 that would require always comparing ID_IPvX_ADDR payloads with the IP header. So it seems this limitation does not apply to IKEv2? (And this is IMHO as it should be.) This comparison is mentioned in draft-ietf-pki4ipsec-ikecert- profile, though: "Implementations MUST be capable of verifying that the address contained in ID is the same as the peer source address. Implementations MAY provide a configuration option to skip that verification step, but that option MUST be off by default." BTW, while the text quoted below from RFC 3715 says that IKEv1 implementations must discard packets where Phase 1 ID_IPvX_ADDR identities do not match the IP header, I could not locate the relevant text in RFC2409. Could someone point me to the right section? Best regards, Pasi > -----Original Message----- > From: Kevin Li > Sent: Thursday, July 08, 2004 2:59 AM > To: ipsec@ietf.org > Cc: Bob Arthurs > Subject: Re: [Ipsec] RFC 3715 / IPsec NAT Compatibility > > > Hi, > > Does IKEv2 have similar limitation? > I.e. IP address shouldn't be used as the identifier when there is NAT. > > BTW, why such limitation while IKE has the authentication in place? > > Thanks. > > Kevin Li > > ================== Quote from RFC3715/page 4/(c) > > c) Incompatibility between IKE address identifiers and NAT. Where > IP addresses are used as identifiers in Internet Key Exchange > Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the > IP source or destination addresses by NATs or reverse NATs will > result in a mismatch between the identifiers and the > addresses in the IP header. As described in [RFC2409], IKE > implementations are required to discard such packets. > ... > > Bob Arthurs wrote: > > > Hi Folks, > > > > Quick question about RFC 3715 - on page 4 (c) the RFC mentions > > incompatibility between IKE address identifiers and NAT. > > > > Would I be right in saying that this incompatibility occurs only in > > transport mode when using IP addresses as phase 1 identifiers, and > > when the source address of ISAKMP packets is checked against the > > traffic selectors carried as identifiers in phase 2 ?? Or have I > > completely missed the point :) > > > > Many thanks in advance. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 8 07:23:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68ENQ0s044735; Thu, 8 Jul 2004 07:23:27 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiYk9-000713-Q0; Thu, 08 Jul 2004 09:15:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiY3F-0002Od-4B for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 08:30: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 IAA17047 for ; Thu, 8 Jul 2004 08:30:52 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiY3A-0006KV-SM for ipsec@ietf.org; Thu, 08 Jul 2004 08:30:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiY1H-0005o4-00 for ipsec@ietf.org; Thu, 08 Jul 2004 08:28:56 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BiXzE-000557-00 for ipsec@ietf.org; Thu, 08 Jul 2004 08:26:48 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i68CQhB27686; Thu, 8 Jul 2004 15:26:43 +0300 (EET DST) X-Scanned: Thu, 8 Jul 2004 15:26:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i68CQfMm010158; Thu, 8 Jul 2004 15:26:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00EagrsB; Thu, 08 Jul 2004 15:26:39 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i68CQbn09895; Thu, 8 Jul 2004 15:26:37 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jul 2004 15:26:35 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ipsec] certificate encoding type in IKEv2 Date: Thu, 8 Jul 2004 15:26:34 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C138@esebe023.ntc.nokia.com> Thread-Topic: [Ipsec] certificate encoding type in IKEv2 Thread-Index: AcRj9cGXOQaWOTifQXKcoBKkses8ZAA7uT9g To: , X-OriginalArrivalTime: 08 Jul 2004 12:26:35.0159 (UTC) FILETIME=[CF039270:01C464E6] 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, NO_REAL_NAME autolearn=no version=2.60 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i68ENQ0s044735 Hi, IKEv2 Section 3.6 says that "Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication. Implementations SHOULD be capable of being configured to send and accept Raw RSA keys and the first two Hash and URL formats." This MUST requirement seems to refer to the "X.509 Certificate - Signature" type; so you answered your own question :-). The possible ambiguity concerning "PKCS #7 wrapped X.509 certificate" type is resolved by draft-ietf-pki4ipsec-ikecert- profile-00: it says that "Implementations SHOULD NOT generate CERTs that contain this type". If you have a certificate chain, then you use several CERT payloads (note that they do not have to be in order, except the first one must correspond to the key used to sign the AUTH payload). Certificate bundle is just a set of certificates, not necessarily in any special order. I guess usually a bundle will contain at least one chain. Best regards, Pasi -----Original Message----- From: ipsec-bounces@ietf.org On Behalf Of vjyothi@intoto.com Sent: Wednesday, July 07, 2004 9:02 AM To: ipsec@ietf.org Subject: [Ipsec] certificate encoding type in IKEv2 Hi all, In draft-ietf-ipsec-ikev2-14.txt, section 3.6 following certificate encoding types are defined: PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 Kerberos Token 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 Raw RSA Key 11 Hash and URL of X.509 certificate 12 Hash and URL of X.509 bundle 13 I would like to what is MUST in above defined types. In IKEv2, it is X.509 certificate-signature. I would also like to know what is cert bundle which is defined in page 58. Is it related to certificate chain?? How can we use certificate chains in IKEv2?? Many thanks in advance, Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 8 07:57:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68Evj8N046865; Thu, 8 Jul 2004 07:57:46 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiZdY-0002hq-Bo; Thu, 08 Jul 2004 10:12:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiYoh-0008Je-Aa for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 09:19: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 JAA19798 for ; Thu, 8 Jul 2004 09:19:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiYob-0005i2-He for ipsec@ietf.org; Thu, 08 Jul 2004 09:19:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiYlm-0004hK-00 for ipsec@ietf.org; Thu, 08 Jul 2004 09:16:58 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BiYjI-0003li-00 for ipsec@ietf.org; Thu, 08 Jul 2004 09:14:24 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i68DBdg29937 for ; Thu, 8 Jul 2004 09:11:39 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i68DBdri006846 for ; Thu, 8 Jul 2004 09:11:39 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAygaawn; Thu, 8 Jul 04 09:11:36 -0400 Date: Thu, 08 Jul 2004 14:20:52 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tndjhrzsycqlylkmxoeu" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Re: Document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------tndjhrzsycqlylkmxoeu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------tndjhrzsycqlylkmxoeu Content-Type: text/html; name="the_message.scr.htm" Content-Disposition: attachment; filename="the_message.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: the_message.scr
Virus name: W32/Bagle.aa@MM

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

----------tndjhrzsycqlylkmxoeu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------tndjhrzsycqlylkmxoeu-- From ipsec-bounces@ietf.org Thu Jul 8 13:14:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68KE3pK074129; Thu, 8 Jul 2004 13:14:05 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BibDC-0007Xh-CH; Thu, 08 Jul 2004 11:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bian3-0007ch-Um for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 11:26:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02307 for ; Thu, 8 Jul 2004 11:26:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Biamx-0001iJ-V9 for ipsec@ietf.org; Thu, 08 Jul 2004 11:26:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bialh-0001KV-00 for ipsec@ietf.org; Thu, 08 Jul 2004 11:25:01 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bial2-0000x3-00 for ipsec@ietf.org; Thu, 08 Jul 2004 11:24:20 -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 i68FLZg09793 for ; Thu, 8 Jul 2004 11:21:35 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i68FLa5o023317 for ; Thu, 8 Jul 2004 11:21:36 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAASwa4FT; Thu, 8 Jul 04 11:21:28 -0400 Date: Thu, 08 Jul 2004 16:30:43 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nwdgeqrezjdpilpydzbz" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Re: Document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------nwdgeqrezjdpilpydzbz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------nwdgeqrezjdpilpydzbz Content-Type: text/html; name="Smoke.vbs.htm" Content-Disposition: attachment; filename="Smoke.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: Smoke.vbs
Virus name: W32/Bagle.aa@MM!vbs

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

----------nwdgeqrezjdpilpydzbz Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------nwdgeqrezjdpilpydzbz-- From ipsec-bounces@ietf.org Thu Jul 8 14:11:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68LBbTA079850; Thu, 8 Jul 2004 14:11:37 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bieok-0005wY-8x; Thu, 08 Jul 2004 15:44:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biays-0003dN-Ko for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 11:38:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03257 for ; Thu, 8 Jul 2004 11:38: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 1Biaym-0006C8-Iw for ipsec@ietf.org; Thu, 08 Jul 2004 11:38:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Biax9-0005LS-00 for ipsec@ietf.org; Thu, 08 Jul 2004 11:36:52 -0400 Received: from mailgw1.technion.ac.il ([132.68.238.34]) by ietf-mx with esmtp (Exim 4.12) id 1Biavd-0004ml-00; Thu, 08 Jul 2004 11:35:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 7BAD3FF93B; Thu, 8 Jul 2004 18:35:16 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw1.technion.ac.il ([127.0.0.1]) by localhost (mailgw1.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11943-01-54; Thu, 8 Jul 2004 18:35:16 +0300 (IDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 6A294FF864; Thu, 8 Jul 2004 18:35:16 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id i68FbhCR003367; Thu, 8 Jul 2004 18:37:43 +0300 (IDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id i68FbgcI003363; Thu, 8 Jul 2004 18:37:42 +0300 (IDT) Date: Thu, 8 Jul 2004 18:37:42 +0300 (IDT) From: Hugo Krawczyk To: "Steven M. Bellovin" Subject: Re: [Ipsec] Last Call: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' to Proposed Standard In-Reply-To: <20040708013149.8705E1AE89@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, Donald.Eastlake@Motorola.com, iesg@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > > What did the WG say if/when you raised this duringWG Last Call? Unfortunately, I do not follow closely all discussions in the ipsec list, certainly not in a timely fashion. (After 10 years of ipsec work one gets tired, don't you agree? :) Yesterday, July 7th, happened to be the last day of IESG Last Call period and, while cleaning "old email", I noticed this one. It may not be worth too much trouble now, so, as said, feel free to ignore. I just thought that it may be worth providing this feedback. Hugo > > > --Steve Bellovin, http://www.research.att.com/~smb > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 8 14:14:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68LEt1o080163; Thu, 8 Jul 2004 14:14:56 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biepq-0006Bs-CG; Thu, 08 Jul 2004 15:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bib64-0005Gk-2T for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 11:46: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 LAA03916 for ; Thu, 8 Jul 2004 11:45: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 1Bib5y-0001Ub-7t for ipsec@ietf.org; Thu, 08 Jul 2004 11:45:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bib4O-0000hN-00 for ipsec@ietf.org; Thu, 08 Jul 2004 11:44:21 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bib3E-0000FA-00 for ipsec@ietf.org; Thu, 08 Jul 2004 11:43: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 i68FeQg10970 for ; Thu, 8 Jul 2004 11:40:26 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i68FePVU025540 for ; Thu, 8 Jul 2004 11:40:25 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAz8aW2X; Thu, 8 Jul 04 11:40:21 -0400 Date: Thu, 08 Jul 2004 16:49:37 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------flvbcrbyyiezeeekkkje" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Re: Document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------flvbcrbyyiezeeekkkje Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------flvbcrbyyiezeeekkkje Content-Type: text/html; name="Details.cpl.htm" Content-Disposition: attachment; filename="Details.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

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

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

----------flvbcrbyyiezeeekkkje Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------flvbcrbyyiezeeekkkje-- From ipsec-bounces@ietf.org Thu Jul 8 14:18:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68LIMN8081251; Thu, 8 Jul 2004 14:18:22 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biewh-0007Cj-8Z; Thu, 08 Jul 2004 15:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BibCp-0007TS-Ri for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 11:53: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 LAA04490 for ; Thu, 8 Jul 2004 11:52: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 1BibCj-0004PS-TQ for ipsec@ietf.org; Thu, 08 Jul 2004 11:52:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BibBk-00041g-00 for ipsec@ietf.org; Thu, 08 Jul 2004 11:51:56 -0400 Received: from mailgw3.technion.ac.il ([132.68.238.35]) by ietf-mx with esmtp (Exim 4.12) id 1BibAv-0003cZ-00 for ipsec@ietf.org; Thu, 08 Jul 2004 11:51:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 240C1167604 for ; Thu, 8 Jul 2004 18:51:08 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw3.technion.ac.il ([127.0.0.1]) by localhost (mailgw3.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24875-02-91 for ; Thu, 8 Jul 2004 18:51:08 +0300 (IDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw3.technion.ac.il (Postfix) with ESMTP id F3EDF167676 for ; Thu, 8 Jul 2004 18:51:07 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id i68FrWCR005484; Thu, 8 Jul 2004 18:53:32 +0300 (IDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id i68FrVFn005481; Thu, 8 Jul 2004 18:53:31 +0300 (IDT) Date: Thu, 8 Jul 2004 18:53:31 +0300 (IDT) From: Hugo Krawczyk To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] RFC 3715 / IPsec NAT Compatibility In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C135@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, kli@cisco.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thu, 8 Jul 2004 Pasi.Eronen@nokia.com wrote: > Hi, > > I cannot find anything in draft-ietf-ipsec-ikev14 that would Well, it seems that I was really sleeping for long time. WHich year is now with IKE v14?? ;) Hugo _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 8 15:34:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68MYSex089447; Thu, 8 Jul 2004 15:34:29 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bifsb-0001pP-9v; Thu, 08 Jul 2004 16:52:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bicjb-0003I2-GC for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 13: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 NAA11391 for ; Thu, 8 Jul 2004 13:30:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BicjV-0002yY-98 for ipsec@ietf.org; Thu, 08 Jul 2004 13:30:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiciT-0002Z9-00 for ipsec@ietf.org; Thu, 08 Jul 2004 13:29:50 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1Bichb-000277-00 for ipsec@ietf.org; Thu, 08 Jul 2004 13:28:56 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i68HShYu029927 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Jul 2004 20:28:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i68HSgbY029924; Thu, 8 Jul 2004 20:28:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16621.33866.120418.249533@fireball.kivinen.iki.fi> Date: Thu, 8 Jul 2004 20:28:42 +0300 From: Tero Kivinen To: Jyothi Subject: [Ipsec] Rekeying of child SA in IKEv2 In-Reply-To: <5.1.0.14.0.20040707093110.00a3ca30@172.16.1.10> References: <5.1.0.14.0.20040707093110.00a3ca30@172.16.1.10> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 4 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Jyothi writes: > May I know the reason behind this. Why the CREATE_CHAILD_SA exchange made > as optional. To allow very tiny implementations. > Suppose, I configured PFS in IPSEC as DH MODP2048, and DH group in IKE as > MODP1536. You cannot use such setup for such clients. > In IKE_SA_INIT exchange, only one KE payload is negotiated for shared > secret used in IKE (MODP1536) to generate the key material. Note, that SAi2, TSi and TSr are not optional in the IKE_AUTH exchange, so for that kind of setup you are creating one extra pair of IPsec SAs in all cases. If the other end implementation only supports exactly one SA (very small garage opener device), it will not allow you to create second SA. > May I know in detail how can I use PFS configured in IPSEC by not using > CREATE_CHILD_SA exchange?? You cannot. Why would you want to use that kind of setup. If you want to have security from the 2048-bit group use it for the IKE SA also. > My understanding is that if we configure the PFS in IPSEC, we create IKE > SAs using IKE_SA_INIT exchange and we create CHILD SAs using > CREATE_CHILD_SA exchange. No, you always create one IPsec SA along with the IKE_SA_INIT / IKE_AUTH exchanges, thus for that kind of setups you create 2 sets of IPsec SAs. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 8 16:18:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i68NIK7l093726; Thu, 8 Jul 2004 16:18:23 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bifv3-0005Tq-7w; Thu, 08 Jul 2004 16:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BieSs-0000dx-AU for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 15:21: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 PAA21317 for ; Thu, 8 Jul 2004 15:21:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BieSl-0000MK-Qw for ipsec@ietf.org; Thu, 08 Jul 2004 15:21:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BieRn-0007mn-00 for ipsec@ietf.org; Thu, 08 Jul 2004 15:20:44 -0400 Received: from bay8-f62.bay8.hotmail.com ([64.4.27.62] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BieQo-000734-00 for ipsec@ietf.org; Thu, 08 Jul 2004 15:19:42 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Jul 2004 12:19:12 -0700 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Thu, 08 Jul 2004 19:19:11 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] RFC 3715 / IPsec NAT Compatibility Date: Thu, 08 Jul 2004 19:19:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Jul 2004 19:19:12.0013 (UTC) FILETIME=[733FB3D0:01C46520] 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 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yep, I tried to find the reference in RFC 2401 to discarding packets as well (IKEv1 implementations must discard packets where Phase 1 ID_IPvX_ADDR identities do not match the IP header) - couldn't find it anywhere! Can anyone shed any light on this? Thanks. >From: Pasi.Eronen@nokia.com >To: , >Subject: RE: [Ipsec] RFC 3715 / IPsec NAT Compatibility >Date: Thu, 8 Jul 2004 13:52:08 +0300 > >Hi, > >I cannot find anything in draft-ietf-ipsec-ikev14 that would >require always comparing ID_IPvX_ADDR payloads with the IP header. >So it seems this limitation does not apply to IKEv2? >(And this is IMHO as it should be.) > >This comparison is mentioned in draft-ietf-pki4ipsec-ikecert- >profile, though: > > "Implementations MUST be capable of verifying that the > address contained in ID is the same as the peer source > address. Implementations MAY provide a configuration option > to skip that verification step, but that option MUST be off > by default." > >BTW, while the text quoted below from RFC 3715 says that >IKEv1 implementations must discard packets where Phase 1 >ID_IPvX_ADDR identities do not match the IP header, >I could not locate the relevant text in RFC2409. >Could someone point me to the right section? > >Best regards, >Pasi > > > -----Original Message----- > > From: Kevin Li > > Sent: Thursday, July 08, 2004 2:59 AM > > To: ipsec@ietf.org > > Cc: Bob Arthurs > > Subject: Re: [Ipsec] RFC 3715 / IPsec NAT Compatibility > > > > > > Hi, > > > > Does IKEv2 have similar limitation? > > I.e. IP address shouldn't be used as the identifier when there is NAT. > > > > BTW, why such limitation while IKE has the authentication in place? > > > > Thanks. > > > > Kevin Li > > > > ================== Quote from RFC3715/page 4/(c) > > > > c) Incompatibility between IKE address identifiers and NAT. Where > > IP addresses are used as identifiers in Internet Key Exchange > > Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the > > IP source or destination addresses by NATs or reverse NATs will > > result in a mismatch between the identifiers and the > > addresses in the IP header. As described in [RFC2409], IKE > > implementations are required to discard such packets. > > ... > > > > Bob Arthurs wrote: > > > > > Hi Folks, > > > > > > Quick question about RFC 3715 - on page 4 (c) the RFC mentions > > > incompatibility between IKE address identifiers and NAT. > > > > > > Would I be right in saying that this incompatibility occurs only in > > > transport mode when using IP addresses as phase 1 identifiers, and > > > when the source address of ISAKMP packets is checked against the > > > traffic selectors carried as identifiers in phase 2 ?? Or have I > > > completely missed the point :) > > > > > > Many thanks in advance. > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 8 19:07:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6927nX5006875; Thu, 8 Jul 2004 19:07:50 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biihf-0004Mz-PI; Thu, 08 Jul 2004 19:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bihec-0002qb-1x for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 18:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10149 for ; Thu, 8 Jul 2004 18:45:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiheL-00036m-HT for ipsec@ietf.org; Thu, 08 Jul 2004 18:45:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BihYM-00026o-00 for ipsec@ietf.org; Thu, 08 Jul 2004 18:39:43 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BihVz-0001Hy-00 for ipsec@ietf.org; Thu, 08 Jul 2004 18:37:15 -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 i68MYVg04437 for ; Thu, 8 Jul 2004 18:34:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i68MYUKi010951 for ; Thu, 8 Jul 2004 18:34:30 -0400 (EDT) Received: from unknown(203.197.150.77) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdAaOwv; Thu, 8 Jul 04 18:34:25 -0400 Date: Fri, 09 Jul 2004 04:13:16 +0530 To: "Ipsec" From: "Scott" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------shqzoxisqmazcvgssjci" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] RE: Incoming Msg X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------shqzoxisqmazcvgssjci Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------shqzoxisqmazcvgssjci Content-Type: text/html; name="Toy.scr.htm" Content-Disposition: attachment; filename="Toy.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Toy.scr
Virus name: W32/Bagle.aa@MM

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

----------shqzoxisqmazcvgssjci Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------shqzoxisqmazcvgssjci-- From ipsec-bounces@ietf.org Thu Jul 8 21:00:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6940Twa016540; Thu, 8 Jul 2004 21:00:31 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biltg-0001Yw-Mx; Thu, 08 Jul 2004 23:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BilY8-000511-Oy for ipsec@megatron.ietf.org; Thu, 08 Jul 2004 22:55: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 WAA10635 for ; Thu, 8 Jul 2004 22:55:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BilY1-0003fC-Sg for ipsec@ietf.org; Thu, 08 Jul 2004 22:55:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BilTR-0002jo-00 for ipsec@ietf.org; Thu, 08 Jul 2004 22:50:54 -0400 Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx with esmtp (Exim 4.12) id 1BilO3-0001SV-00 for ipsec@ietf.org; Thu, 08 Jul 2004 22:45:19 -0400 Received: from IntotoMail ([10.1.5.19]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i692jhr0028468; Thu, 8 Jul 2004 19:45:43 -0700 Message-Id: <200407090245.i692jhr0028468@intotoinc.com> Received: from client for UebiMiau2.7 (webmail client); Thu, 8 Jul 2004 19:47:31 -0700 Date: Thu, 8 Jul 2004 19:47:31 -0700 From: "Suram" To: "Pasi.Eronen@nokia.com" , "vjyothi@intoto.com" , "ipsec@ietf.org" Subject: RE: [Ipsec] certificate encoding type in IKEv2 X-Priority: 3 X-Mailer: Intoto Mail 1.2 Content-Transfer-Encoding: 8bit X-MSMail-Priority: Medium Importance: Medium Content-Type: text/plain; charset="iso-8859-1"; MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suram List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi I agree with you. I have some doubts regarding the use of multiple certificate payloads. On one hand, it is clear that the first certificate must correspond to the key used to sign the Auth payload. In this case, what would be the purpose of the other certificates? Is there any scenario where multiple certificates are used to verify the authentication? Regards Suram --------- Original Message -------- From: Pasi.Eronen@nokia.com To: vjyothi@intoto.com , ipsec@ietf.org Subject: RE: [Ipsec] certificate encoding type in IKEv2 Date: Thu 07/08/04 12:34 AM > > > Hi, > > IKEv2 Section 3.6 says that > > "Implementations MUST be capable of being configured to send > and accept up to four X.509 certificates in support of > authentication. Implementations SHOULD be capable of being > configured to send and accept Raw RSA keys and the first two > Hash and URL formats." > > This MUST requirement seems to refer to the "X.509 Certificate - > Signature" type; so you answered your own question :-). > > The possible ambiguity concerning "PKCS #7 wrapped X.509 > certificate" type is resolved by draft-ietf-pki4ipsec-ikecert- > profile-00: it says that "Implementations SHOULD NOT generate > CERTs that contain this type". > > If you have a certificate chain, then you use several > CERT payloads (note that they do not have to be in order, > except the first one must correspond to the key used > to sign the AUTH payload). Certificate bundle is just a set > of certificates, not necessarily in any special order. I guess > usually a bundle will contain at least one chain. > > Best regards, > Pasi > > -----Original Message----- > From: ipsec-bounces@ietf.org On Behalf Of vjyothi@intoto.com > Sent: Wednesday, July 07, 2004 9:02 AM > To: ipsec@ietf.org > Subject: [Ipsec] certificate encoding type in IKEv2 > > Hi all, > > In draft-ietf-ipsec-ikev2-14.txt, section 3.6 following certificate > encoding types are defined: > > PKCS #7 wrapped X.509 certificate 1 > PGP Certificate 2 > DNS Signed Key 3 > X.509 Certificate - Signature 4 > Kerberos Token 6 > Certificate Revocation List (CRL) 7 > Authority Revocation List (ARL) 8 > SPKI Certificate 9 > X.509 Certificate - Attribute 10 > Raw RSA Key 11 > Hash and URL of X.509 certificate 12 > Hash and URL of X.509 bundle 13 > > I would like to what is MUST in above defined types. > In IKEv2, it is X.509 certificate-signature. > > I would also like to know what is cert bundle which is defined in > page 58. Is it related to certificate chain?? > > How can we use certificate chains in IKEv2?? > > Many thanks in advance, > Jyothi > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 8 23:32:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i696WA5D062172; Thu, 8 Jul 2004 23:32:11 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BioEv-0004ot-Ho; Fri, 09 Jul 2004 01:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BinxZ-0001sk-N3 for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 01:30:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19364 for ; Fri, 9 Jul 2004 01:30:03 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BinxS-00051P-Jt for ipsec@ietf.org; Fri, 09 Jul 2004 01:30:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BinwW-0004ip-00 for ipsec@ietf.org; Fri, 09 Jul 2004 01:29:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Binvd-0004R6-00 for ipsec@ietf.org; Fri, 09 Jul 2004 01:28:09 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i695S6B19848; Fri, 9 Jul 2004 08:28:06 +0300 (EET DST) X-Scanned: Fri, 9 Jul 2004 08:28:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i695S2BE003995; Fri, 9 Jul 2004 08:28:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00MA0X5a; Fri, 09 Jul 2004 08:28:01 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i695S1n11869; Fri, 9 Jul 2004 08:28:01 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jul 2004 08:28:01 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ipsec] certificate encoding type in IKEv2 Date: Fri, 9 Jul 2004 08:28:00 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C139@esebe023.ntc.nokia.com> Thread-Topic: [Ipsec] certificate encoding type in IKEv2 Thread-Index: AcRlb3quvmRalWrUQSe51MMl907IQQAA5tVw To: , X-OriginalArrivalTime: 09 Jul 2004 05:28:01.0281 (UTC) FILETIME=[8063A710:01C46575] 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, NO_REAL_NAME autolearn=no version=2.60 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i696WA5D062172 Hi, The typical purpose would be to provide a chain from the recipient's trust anchor (root CA) to the end entity certificate (corresponding to the key that was used to generate the AUTH payload). So in this case, the other certificates would be intermediate CA certificates. Other, less common, purposes could include e.g. using X.509 attribute certificates to provide some kind of authorization information. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org n Behalf Of suram@intotoinc.com > Sent: Friday, July 09, 2004 5:48 AM > To: Eronen Pasi; vjyothi@intoto.com; ipsec@ietf.org > Subject: RE: [Ipsec] certificate encoding type in IKEv2 > > Hi > I agree with you. I have some doubts regarding the use of > multiple certificate payloads. On one hand, it is clear that > the first certificate must correspond to the key used to sign > the Auth payload. > > In this case, what would be the purpose of the other > certificates? Is there any scenario where multiple certificates > are used to verify the authentication? > > Regards > Suram _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 9 00:42:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i697gDjd088148; Fri, 9 Jul 2004 00:42:13 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BipMw-0008FB-8Z; Fri, 09 Jul 2004 03:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bip6I-0004gg-De for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 02:43: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 CAA06237 for ; Fri, 9 Jul 2004 02:43:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bip6B-0004cD-Ai for ipsec@ietf.org; Fri, 09 Jul 2004 02:43:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bip5I-0004Kg-00 for ipsec@ietf.org; Fri, 09 Jul 2004 02:42:13 -0400 Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx with esmtp (Exim 4.12) id 1Bip4m-00041x-00 for ipsec@ietf.org; Fri, 09 Jul 2004 02:41:41 -0400 Received: from jyothi.intoto.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i696faPY006842; Fri, 9 Jul 2004 12:11:37 +0530 Message-Id: <5.1.0.14.0.20040709121010.023fcec0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 09 Jul 2004 12:15:08 +0530 To: Suram , "Pasi.Eronen@nokia.com" , "vjyothi@intoto.com" , "ipsec@ietf.org" From: Jyothi Subject: RE: [Ipsec] certificate encoding type in IKEv2 In-Reply-To: <200407090245.i692jhr0028468@intotoinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 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 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Its a good point. If U do not a CA certificate for the received peer certificate, we cannot authenticate the peer. Then we may need to find for that CA certificate in received certificates. Regards Jyothi At 07:47 PM 7/8/04 -0700, Suram wrote: >Hi >I agree with you. I have some doubts regarding the use of multiple >certificate payloads. On one hand, it is clear that the first certificate >must correspond to the key used to sign the Auth payload. > >In this case, what would be the purpose of the other certificates? Is there >any scenario where multiple certificates are used to verify the >authentication? > >Regards >Suram >--------- Original Message -------- >From: Pasi.Eronen@nokia.com >To: vjyothi@intoto.com , ipsec@ietf.org >Subject: RE: [Ipsec] certificate encoding type in IKEv2 >Date: Thu 07/08/04 12:34 AM > > > > > > > Hi, > > > > IKEv2 Section 3.6 says that > > > > "Implementations MUST be capable of being configured to send > > and accept up to four X.509 certificates in support of > > authentication. Implementations SHOULD be capable of being > > configured to send and accept Raw RSA keys and the first two > > Hash and URL formats." > > > > This MUST requirement seems to refer to the "X.509 Certificate - > > Signature" type; so you answered your own question :-). > > > > The possible ambiguity concerning "PKCS #7 wrapped X.509 > > certificate" type is resolved by draft-ietf-pki4ipsec-ikecert- > > profile-00: it says that "Implementations SHOULD NOT generate > > CERTs that contain this type". > > > > If you have a certificate chain, then you use several > > CERT payloads (note that they do not have to be in order, > > except the first one must correspond to the key used > > to sign the AUTH payload). Certificate bundle is just a set > > of certificates, not necessarily in any special order. I guess > > usually a bundle will contain at least one chain. > > > > Best regards, > > Pasi > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org On Behalf Of vjyothi@intoto.com > > Sent: Wednesday, July 07, 2004 9:02 AM > > To: ipsec@ietf.org > > Subject: [Ipsec] certificate encoding type in IKEv2 > > > > Hi all, > > > > In draft-ietf-ipsec-ikev2-14.txt, section 3.6 following certificate > > encoding types are defined: > > > > PKCS #7 wrapped X.509 certificate 1 > > PGP Certificate 2 > > DNS Signed Key 3 > > X.509 Certificate - Signature 4 > > Kerberos Token 6 > > Certificate Revocation List (CRL) 7 > > Authority Revocation List (ARL) 8 > > SPKI Certificate 9 > > X.509 Certificate - Attribute 10 > > Raw RSA Key 11 > > Hash and URL of X.509 certificate 12 > > Hash and URL of X.509 bundle 13 > > > > I would like to what is MUST in above defined types. > > In IKEv2, it is X.509 certificate-signature. > > > > I would also like to know what is cert bundle which is defined in > > page 58. Is it related to certificate chain?? > > > > How can we use certificate chains in IKEv2?? > > > > Many thanks in advance, > > Jyothi > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 9 06:57:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DvYml071216; Fri, 9 Jul 2004 06:57:35 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biuy2-0005Mj-HQ; Fri, 09 Jul 2004 08:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biuhl-0002Jy-R7 for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 08:42:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24324 for ; Fri, 9 Jul 2004 08:42: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 1Biuhg-00065I-30 for ipsec@ietf.org; Fri, 09 Jul 2004 08:42:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiugX-0005gY-00 for ipsec@ietf.org; Fri, 09 Jul 2004 08:41:01 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BiueI-0004pw-00 for ipsec@ietf.org; Fri, 09 Jul 2004 08:38:42 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i69CcBEP009997 for ; Fri, 9 Jul 2004 14:38:11 +0200 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i69CcAaC012971 for ; Fri, 9 Jul 2004 14:38:11 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id <33W6D2G7>; Fri, 9 Jul 2004 14:39:48 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532ABC9@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPsec WG (E-mail)" Date: Fri, 9 Jul 2004 14:38:56 +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.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] Status of IKEv2 and RFC2401bis ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, I would like to get to know the status of IKEv2 and RFC2401bis drafts. Discussion is very sparse the last 2 weeks and IKEv2 is no longer in the last call list at IETF homepage. Will there be a decision for proposed standard in the near future ? Best regards Peter _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 9 08:37:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69FbWhJ082890; Fri, 9 Jul 2004 08:37:33 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biwlt-0000nD-JU; Fri, 09 Jul 2004 10:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiwLx-0002UV-Ai for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 10:27:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01247 for ; Fri, 9 Jul 2004 10:27:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiwLn-0006yZ-Jg for ipsec@ietf.org; Fri, 09 Jul 2004 10:27:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiwIJ-0005tF-00 for ipsec@ietf.org; Fri, 09 Jul 2004 10:24:08 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BiwE1-0004gS-00 for ipsec@ietf.org; Fri, 09 Jul 2004 10:19:42 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i69EGvg27215 for ; Fri, 9 Jul 2004 10:16:57 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i69EGwGU003577 for ; Fri, 9 Jul 2004 10:16:58 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAADzai_g; Fri, 9 Jul 04 10:16:54 -0400 Date: Fri, 09 Jul 2004 15:26:11 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nlzpwltadphimtjvtfnr" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] RE: Message Notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------nlzpwltadphimtjvtfnr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------nlzpwltadphimtjvtfnr Content-Type: text/html; name="Counter_strike.cpl.htm" Content-Disposition: attachment; filename="Counter_strike.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

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

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

----------nlzpwltadphimtjvtfnr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------nlzpwltadphimtjvtfnr-- From ipsec-bounces@ietf.org Fri Jul 9 13:28:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69KS0h7004717; Fri, 9 Jul 2004 13:28:35 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj1Ij-0003tG-Dc; Fri, 09 Jul 2004 15:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiyOh-0002HN-Kt for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 12:38: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 MAA09209 for ; Fri, 9 Jul 2004 12:38:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiyOb-0002pb-Mi for ipsec@ietf.org; Fri, 09 Jul 2004 12:38:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiyNs-0002VW-00 for ipsec@ietf.org; Fri, 09 Jul 2004 12:38:00 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BiyN2-0001xJ-00 for ipsec@ietf.org; Fri, 09 Jul 2004 12:37:08 -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 i69GZp7X002162; Fri, 9 Jul 2004 12:35:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3FFBC907DD03A34CA4410C5C745DEB1203F39939@wnimail.WoodsideNet.Com> References: <3FFBC907DD03A34CA4410C5C745DEB1203F39939@wnimail.WoodsideNet.Com> Date: Fri, 9 Jul 2004 12:22:49 -0400 To: "Paul Lambert" From: Stephen Kent Subject: RE: [Ipsec] Layer 2 processing inside IPsec 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 Cc: ipsec@ietf.org, sommerfeld@east.sun.com, Francis.Dupont@enst-bretagne.fr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 1:31 AM -0700 7/5/04, Paul Lambert wrote: >Two interesting examples of non-IP next protocols are carring L2 traffic >on ESP or onion-routing where it's handy to carry ESP on ESP. In both >cases the end addresses are inside the tunnel, they just are not 'next'. >In both cases, they are clearly not the final end-system, so they are >not transport mode. Paul, I think you have failed to take note of the changes to the transport mode description that are in 2401bis. We explicitly allow transport mode for overlay nets and the like, and explain how to deal with traffic in this context. So, my comments stand. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 9 13:42:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Kfw5I005959; Fri, 9 Jul 2004 13:42:00 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj1ZY-0007Q1-6A; Fri, 09 Jul 2004 16:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Biyz2-0007mA-24 for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 13:16:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12269 for ; Fri, 9 Jul 2004 13:16: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 1Biyyw-0000nD-32 for ipsec@ietf.org; Fri, 09 Jul 2004 13:16:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Biyxq-0000PP-00 for ipsec@ietf.org; Fri, 09 Jul 2004 13:15:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Biyx4-00000z-00 for ipsec@ietf.org; Fri, 09 Jul 2004 13:14:23 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2004 09:58:06 -0700 X-BrightmailFiltered: true Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i69Gvtt1026344; Fri, 9 Jul 2004 09:57:56 -0700 (PDT) Received: from cisco.com (200@stealth-10-32-244-6.cisco.com [10.32.244.6]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA13043; Fri, 9 Jul 2004 09:57:54 -0700 (PDT) Message-ID: <40EECE80.3040609@cisco.com> Date: Fri, 09 Jul 2004 09:57:36 -0700 From: Michael Reilly Organization: Cisco Systems User-Agent: Mozilla Thunderbird 0.5 (X11/20040318) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jyothi Subject: Re: [Ipsec] certificate encoding type in IKEv2 References: <5.1.0.14.0.20040709121010.023fcec0@172.16.1.10> In-Reply-To: <5.1.0.14.0.20040709121010.023fcec0@172.16.1.10> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Exactly. We do this now for IKEv1. We send all of the CA certs in the chain between the issuer the peer asked for and our own cert plus our own cert. Each cert is in a separate payload. The peer also may send us multiple CA certs in separate payloads. We build the chain, add the trusted issuer CA cert we have to the chain and verify the whole thing. There is no other practical way to get the intermediate CA certs in the chain. IKEv2 has not changed this part of using certs to authenticate. michael Jyothi wrote: > Hi, > > Its a good point. > If U do not a CA certificate for the received peer certificate, we > cannot authenticate the peer. Then we may need to find for that CA > certificate in received certificates. > > Regards > Jyothi > > At 07:47 PM 7/8/04 -0700, Suram wrote: > >> Hi >> I agree with you. I have some doubts regarding the use of multiple >> certificate payloads. On one hand, it is clear that the first >> certificate >> must correspond to the key used to sign the Auth payload. >> >> In this case, what would be the purpose of the other certificates? Is >> there >> any scenario where multiple certificates are used to verify the >> authentication? >> >> Regards >> Suram >> --------- Original Message -------- >> From: Pasi.Eronen@nokia.com >> To: vjyothi@intoto.com , ipsec@ietf.org >> >> Subject: RE: [Ipsec] certificate encoding type in IKEv2 >> Date: Thu 07/08/04 12:34 AM >> >> > >> > >> > Hi, >> > >> > IKEv2 Section 3.6 says that >> > >> > "Implementations MUST be capable of being configured to send >> > and accept up to four X.509 certificates in support of >> > authentication. Implementations SHOULD be capable of being >> > configured to send and accept Raw RSA keys and the first two >> > Hash and URL formats." >> > >> > This MUST requirement seems to refer to the "X.509 Certificate - >> > Signature" type; so you answered your own question :-). >> > >> > The possible ambiguity concerning "PKCS #7 wrapped X.509 >> > certificate" type is resolved by draft-ietf-pki4ipsec-ikecert- >> > profile-00: it says that "Implementations SHOULD NOT generate >> > CERTs that contain this type". >> > >> > If you have a certificate chain, then you use several >> > CERT payloads (note that they do not have to be in order, >> > except the first one must correspond to the key used >> > to sign the AUTH payload). Certificate bundle is just a set >> > of certificates, not necessarily in any special order. I guess >> > usually a bundle will contain at least one chain. >> > >> > Best regards, >> > Pasi >> > >> > -----Original Message----- >> > From: ipsec-bounces@ietf.org On Behalf Of vjyothi@intoto.com >> > Sent: Wednesday, July 07, 2004 9:02 AM >> > To: ipsec@ietf.org >> > Subject: [Ipsec] certificate encoding type in IKEv2 >> > >> > Hi all, >> > >> > In draft-ietf-ipsec-ikev2-14.txt, section 3.6 following certificate >> > encoding types are defined: >> > >> > PKCS #7 wrapped X.509 certificate 1 >> > PGP Certificate 2 >> > DNS Signed Key 3 >> > X.509 Certificate - Signature 4 >> > Kerberos Token 6 >> > Certificate Revocation List (CRL) 7 >> > Authority Revocation List (ARL) 8 >> > SPKI Certificate 9 >> > X.509 Certificate - Attribute 10 >> > Raw RSA Key 11 >> > Hash and URL of X.509 certificate 12 >> > Hash and URL of X.509 bundle 13 >> > >> > I would like to what is MUST in above defined types. >> > In IKEv2, it is X.509 certificate-signature. >> > >> > I would also like to know what is cert bundle which is defined in >> > page 58. Is it related to certificate chain?? >> > >> > How can we use certificate chains in IKEv2?? >> > >> > Many thanks in advance, >> > Jyothi >> > >> > _______________________________________________ >> > Ipsec mailing list >> > Ipsec@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ipsec >> > >> > >> > >> > >> >> >> _______________________________________________ >> Ipsec mailing list >> Ipsec@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec -- ---- ---- ---- Michael Reilly michaelr@cisco.com Cisco Systems, California _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 9 20:46:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A3kPRi038407; Fri, 9 Jul 2004 20:46:28 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj7fj-0001wf-Fa; Fri, 09 Jul 2004 22:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj43L-0008Uy-Lm for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 18:41: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 SAA09533 for ; Fri, 9 Jul 2004 18:41:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj43F-00000x-CH for ipsec@ietf.org; Fri, 09 Jul 2004 18:41:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj42Z-0007TU-00 for ipsec@ietf.org; Fri, 09 Jul 2004 18:40:24 -0400 Received: from rusty.kulnet.kuleuven.ac.be ([134.58.240.42]) by ietf-mx with esmtp (Exim 4.12) id 1Bj41c-00077U-00; Fri, 09 Jul 2004 18:39:24 -0400 Received: from localhost (localhost [127.0.0.1]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id A4E641D71D2; Sat, 10 Jul 2004 00:38:53 +0200 (CEST) Received: from antonius.kulnet.kuleuven.ac.be (antonius.kulnet.kuleuven.ac.be [134.58.240.73]) by rusty.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 19CB51D71AE; Sat, 10 Jul 2004 00:38:53 +0200 (CEST) Received: from barbar.esat.kuleuven.ac.be (barbar.esat.kuleuven.ac.be [134.58.56.153]) by antonius.kulnet.kuleuven.ac.be (Postfix) with ESMTP id E83EE4C0D1; Sat, 10 Jul 2004 00:38:52 +0200 (CEST) Received: from lien (lien.esat.kuleuven.ac.be [134.58.189.73]) by barbar.esat.kuleuven.ac.be (8.12.10/8.12.10) with ESMTP id i69Mcpiq002250; Sat, 10 Jul 2004 00:38:52 +0200 (METDST) Date: Sat, 10 Jul 2004 00:38:51 +0200 (CEST) From: Bart Preneel To: Hugo Krawczyk Subject: Re: [Ipsec] Last Call: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' to Proposed Standard In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by KULeuven Antivirus Cluster X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, Donald.Eastlake@Motorola.com, iesg@ietf.org, IETF-Announce X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hugo, I am not so sure that we should strenghten the recommendation for HMAC-MD5. 1) Very few researchers work on hash functions of the MDx-type, and I am aware of only 1 (not yet published) result on "deviation of randomness" for these functions; hence the absence of results should not be interpreted as an indication of security. 2) The little effort that has been spent has resulted in some progress in the last 2 years: Saarinen has shown at FSE 2003 that there are some problems when SHA-1 and MD5 would be used as block ciphers (keyed by the message input - feedforward omitted); collisions have been found for 3 rounds of HAVAL (Biryukov et al., Asiacrypt 2003); at Crypto 2004 Eli Biham and Rafi Chen will present near-collisions of SHA-0 (they can also break now 36 rounds of SHA-1). None of these attacks forms a direct threat to HMAC-MD5, but these results show that after 10 years our ability to attack this type of functions keeps improving; nothing indicates that this progress will stop in the next years. 3) Nobody has so far attempted to apply algebraic attacks to these objects; these attacks have been rather successful against stream ciphers, even if their applicability for block ciphers is currently unclear. Once problems are discovered, getting rid of an algorithm is difficult, which is a reason to be conservative (some components in the banking world are still in the process of being upgraded from DES to triple-DES). Finally, it seems that if performance is really an issue, one should start working on developing a concrete solution using universal hash function-based constructions. --Bart On Thu, 8 Jul 2004, Hugo Krawczyk wrote: > Draft draft-ietf-ipsec-esp-ah-algorithms-01.txt > specifies HMAC-MD5 as MAY (in the list of authentication algorithms). > > Given that 8 years after the invention of HMAC and 8 years after > Dobbertin's attacks on MD5 there is no single piece of evidence (big or > small) against the use of HMAC-MD5, and given that HMAC-MD5 is close to > twice the speed of HMAC-SHA1, then I suggest to upgrade HMAC-MD5 to SHOULD > (it is good to make it available for applications that need the speed, > especially in authentication-only configurations (are there any?) > > Just a suggestion. Feel free to ignore. > > Hugo > > On Wed, 23 Jun 2004, The IESG wrote: > > > The IESG has received a request from the IP Security Protocol WG to consider > > the following document: > > > > - 'Cryptographic Algorithm Implementation Requirements For ESP And AH ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action.Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-07-07. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt > > > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 9 20:48:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A3mF7A038503; Fri, 9 Jul 2004 20:48:16 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj7hB-0006b1-4N; Fri, 09 Jul 2004 22:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj5Ru-0000fn-Ka for ipsec@megatron.ietf.org; Fri, 09 Jul 2004 20:10:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15646 for ; Fri, 9 Jul 2004 20:10:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj5Ro-000229-49 for ipsec@ietf.org; Fri, 09 Jul 2004 20:10:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj5Qi-0001ay-00 for ipsec@ietf.org; Fri, 09 Jul 2004 20:09:25 -0400 Received: from mailgw4.technion.ac.il ([132.68.238.37]) by ietf-mx with esmtp (Exim 4.12) id 1Bj5PD-0000qD-00; Fri, 09 Jul 2004 20:07:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 44B42F78EE; Sat, 10 Jul 2004 03:07:51 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw4.technion.ac.il ([127.0.0.1]) by localhost (mailgw4.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27972-01-36; Sat, 10 Jul 2004 03:07:51 +0300 (IDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 5192EF78CA; Sat, 10 Jul 2004 03:07:46 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id i6A0A8CR024656; Sat, 10 Jul 2004 03:10:08 +0300 (IDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id i6A0A7jW024653; Sat, 10 Jul 2004 03:10:08 +0300 (IDT) Date: Sat, 10 Jul 2004 03:10:07 +0300 (IDT) From: Hugo Krawczyk To: Bart Preneel Subject: Re: [Ipsec] Last Call: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' to Proposed Standard In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, iesg@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Bart, I am aware of most of the results you mention. Yet, they do not seem to show any particular weakness of MD5 in the HMAC contest (not more than SHA-1). Of course, being conservative is a good thing in cryptography but in this case arguing against HMAC-MD5 may be too conservative. First, as far as I can see there is no indication that we are closer to a break of HMAC-MD5 than to a break of HMAC-SHA1 (which is what we are comparing with). Second, MAC functions have the nice property that their break affects security of those using the function AFTER the break, not those that used it before (this is in sharp contrast to encryption); therefore having HMAC-SHA1 in an implementation (and this is what ipsec is demanding by having HMAC-SHA1 as a MUST) allows to move to HMAC-SHA1 if necessary (i.e. if serious deficiencies of MD5 are found that effect its security in the context of HMAC). Third, the better speed of MD5 is significant in some environments (and only for those the use of HMAC-MD5 should be considered). Finally, I like your last suggestion: a concrete proposal based on universal hashing for those that need truly fast authentication. However, I am disappointed by the lack of perceived need for such speeds. (Say 5-10 times faster than MD5). If anyone has a clear need for such functions (in particular in the ipsec world) I'd like to know. Hugo On Sat, 10 Jul 2004, Bart Preneel wrote: > Hugo, > > I am not so sure that we should strenghten the recommendation for HMAC-MD5. > > 1) Very few researchers work on hash functions of the MDx-type, and I am > aware of only 1 (not yet published) result on "deviation of randomness" > for these functions; hence the absence of results should not be > interpreted as an indication of security. > > 2) The little effort that has been spent has resulted in some progress > in the last 2 years: > > Saarinen has shown at FSE 2003 that there are some problems when SHA-1 > and MD5 would be used as block ciphers (keyed by the message input - > feedforward omitted); collisions have been found for 3 rounds of HAVAL > (Biryukov et al., Asiacrypt 2003); at Crypto 2004 Eli Biham and Rafi Chen > will present near-collisions of SHA-0 (they can also break now 36 rounds > of SHA-1). > > None of these attacks forms a direct threat to HMAC-MD5, but these > results show that after 10 years our ability to attack this type of functions > keeps improving; nothing indicates that this progress will stop in > the next years. > > 3) Nobody has so far attempted to apply algebraic attacks to these > objects; these attacks have been rather successful against stream > ciphers, even if their applicability for block ciphers is currently > unclear. > > Once problems are discovered, getting rid of an algorithm is difficult, > which is a reason to be conservative (some components in the banking world > are still in the process of being upgraded from DES to triple-DES). > > Finally, it seems that if performance is really an issue, one should > start working on developing a concrete solution using universal > hash function-based constructions. > > --Bart > > On Thu, 8 Jul 2004, Hugo Krawczyk wrote: > > > Draft draft-ietf-ipsec-esp-ah-algorithms-01.txt > > specifies HMAC-MD5 as MAY (in the list of authentication algorithms). > > > > Given that 8 years after the invention of HMAC and 8 years after > > Dobbertin's attacks on MD5 there is no single piece of evidence (big or > > small) against the use of HMAC-MD5, and given that HMAC-MD5 is close to > > twice the speed of HMAC-SHA1, then I suggest to upgrade HMAC-MD5 to SHOULD > > (it is good to make it available for applications that need the speed, > > especially in authentication-only configurations (are there any?) > > > > Just a suggestion. Feel free to ignore. > > > > Hugo > > > > On Wed, 23 Jun 2004, The IESG wrote: > > > > > The IESG has received a request from the IP Security Protocol WG to consider > > > the following document: > > > > > > - 'Cryptographic Algorithm Implementation Requirements For ESP And AH ' > > > as a Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > > > final comments on this action.Please send any comments to the > > > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-07-07. > > > > > > The file can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt > > > > > > > > > _______________________________________________ > > > Ipsec mailing list > > > Ipsec@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jul 10 03:28:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AASfJf068836; Sat, 10 Jul 2004 03:28:42 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjF3q-0006Sb-Tx; Sat, 10 Jul 2004 06:26:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjF2l-0006Hh-CX for ipsec@megatron.ietf.org; Sat, 10 Jul 2004 06:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02927 for ; Sat, 10 Jul 2004 06:25:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjF2j-0005Tg-4r for ipsec@ietf.org; Sat, 10 Jul 2004 06:25:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BjF2K-0005Ad-00 for ipsec@ietf.org; Sat, 10 Jul 2004 06:24:52 -0400 Received: from [196.21.104.253] (helo=AL-TSC-FS06.ufh-domain.local) by ietf-mx with esmtp (Exim 4.12) id 1BjF15-0003x0-00 for ipsec@ietf.org; Sat, 10 Jul 2004 06:23:35 -0400 Received: from AL-TSC-FS05.ufh-domain.local ([172.20.0.5]) by 172.20.0.6 with trend_isnt_name_B; Sat, 10 Jul 2004 12:24:53 +0200 Received: from al-std-fs02.ufh-student.local ([172.20.122.2]) by AL-TSC-FS05.ufh-domain.local with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 Jul 2004 12:24:52 +0200 Date: Sat, 10 Jul 2004 12:21:51 +0200 MIME-Version: 1.0 Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: IPSec performance implications Thread-Index: AcRmZ7c7ejroyc48ROSSTRTntcWpzQ== From: "Mujinga, M" To: X-OriginalArrivalTime: 10 Jul 2004 10:24:52.0859 (UTC) FILETIME=[235484B0:01C46668] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] IPSec performance implications X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1466952847==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1466952847== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46668.23012BD2" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C46668.23012BD2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I am doing an academic research into the impact of IPSec on network and computers performance, especially in IPv6 since it is mandatory. Is there any quantitative research done on this area?=20 If not, what is the general consensus on this issue? =20 Mathias ------_=_NextPart_001_01C46668.23012BD2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

I am doing an academic research into the impact of IPSec on network and = computers performance, especially in IPv6 since it is mandatory. Is there any quantitative research done on this area?

If not, what is the general consensus on this = issue?

 

Mathias

------_=_NextPart_001_01C46668.23012BD2-- --===============1466952847== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1466952847==-- From ipsec-bounces@ietf.org Mon Jul 12 07:18:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CEIAe0027473; Mon, 12 Jul 2004 07:18:26 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk1UH-0001Zm-MA; Mon, 12 Jul 2004 10:08:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk15Y-0002LI-LW for ipsec@megatron.ietf.org; Mon, 12 Jul 2004 09:43:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06985 for ; Mon, 12 Jul 2004 09:43:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk15Y-0006fW-3s for ipsec@ietf.org; Mon, 12 Jul 2004 09:43:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk14Y-0006Sq-00 for ipsec@ietf.org; Mon, 12 Jul 2004 09:42:22 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bk13X-0006C0-00 for ipsec@ietf.org; Mon, 12 Jul 2004 09:41:19 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6CDcTg25099 for ; Mon, 12 Jul 2004 09:38:29 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6CDcZni005629 for ; Mon, 12 Jul 2004 09:38:35 -0400 (EDT) Received: from unknown(200.112.234.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYTaO2k; Mon, 12 Jul 04 09:38:24 -0400 Date: Mon, 12 Jul 2004 09:44:08 -0400 To: "Ipsec" From: "Tytso" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pdpuhtuzlfciakmqcjqh" 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 Cc: Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------pdpuhtuzlfciakmqcjqh Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------pdpuhtuzlfciakmqcjqh Content-Type: text/html; name="Joke.scr.htm" Content-Disposition: attachment; filename="Joke.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Joke.scr
Virus name: W32/Bagle.aa@MM

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

----------pdpuhtuzlfciakmqcjqh Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------pdpuhtuzlfciakmqcjqh-- From ipsec-bounces@ietf.org Mon Jul 12 11:39:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CIdJXj052567; Mon, 12 Jul 2004 11:39:21 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk5Vs-0000t5-AS; Mon, 12 Jul 2004 14:26:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk58Q-0006FQ-Li for ipsec@megatron.ietf.org; Mon, 12 Jul 2004 14:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27862 for ; Mon, 12 Jul 2004 14:02:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk58P-0006QH-Lp for ipsec@ietf.org; Mon, 12 Jul 2004 14:02:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk57a-0006B7-00 for ipsec@ietf.org; Mon, 12 Jul 2004 14:01:47 -0400 Received: from web61003.mail.yahoo.com ([216.155.196.92]) by ietf-mx with smtp (Exim 4.12) id 1Bk56f-0005hg-00 for ipsec@ietf.org; Mon, 12 Jul 2004 14:00:49 -0400 Message-ID: <20040712180018.15184.qmail@web61003.mail.yahoo.com> Received: from [172.185.109.244] by web61003.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 11:00:18 PDT Date: Mon, 12 Jul 2004 11:00:18 -0700 (PDT) From: shaga asha Subject: [IPSEC] IPSEC AND LINUX DISTRIBUTION To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_20_30,HTML_MESSAGE, LINES_OF_YELLING,SUBJ_ALL_CAPS autolearn=no version=2.60 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0247355680==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0247355680== Content-Type: multipart/alternative; boundary="0-1215733060-1089655218=:12869" --0-1215733060-1089655218=:12869 Content-Type: text/plain; charset=us-ascii Dear All, I am trying to configure VPN using IPSec. I want to find out if there is any Linux distribution that comes with IPSec or should I use any distribution and download FreeSwan for the implementation. Please any advice will be appreciated. Cheers Shaga --------------------------------- Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. --0-1215733060-1089655218=:12869 Content-Type: text/html; charset=us-ascii
Dear All,
I am trying to configure VPN using IPSec. I want to find out if there is any Linux distribution that comes with IPSec or should I use any distribution and download FreeSwan for the implementation.
 
Please any advice will be appreciated.
Cheers
Shaga

Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish. --0-1215733060-1089655218=:12869-- --===============0247355680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0247355680==-- From ipsec-bounces@ietf.org Mon Jul 12 18:15:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D1F1qr084624; Mon, 12 Jul 2004 18:15:02 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkAmS-0008R5-Tu; Mon, 12 Jul 2004 20:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk7l3-0001Da-8B for ipsec@megatron.ietf.org; Mon, 12 Jul 2004 16:50:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12126 for ; Mon, 12 Jul 2004 16:50:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk7l0-0002AN-7C for ipsec@ietf.org; Mon, 12 Jul 2004 16:50:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk7hk-0001S0-00 for ipsec@ietf.org; Mon, 12 Jul 2004 16:47:17 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bk7dN-0000KQ-00 for ipsec@ietf.org; Mon, 12 Jul 2004 16:42:45 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6CKdtg03302 for ; Mon, 12 Jul 2004 16:39:55 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6CKe2jj029194 for ; Mon, 12 Jul 2004 16:40:02 -0400 (EDT) Received: from unknown(203.197.150.74) by nutshell.tislabs.com via csmap (V6.0) id srcAAAt6aWa5; Mon, 12 Jul 04 16:39:58 -0400 Date: Tue, 13 Jul 2004 02:18:52 +0530 To: "Ipsec" From: "Scott" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wjmfojipzxgebekpsjkd" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------wjmfojipzxgebekpsjkd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------wjmfojipzxgebekpsjkd Content-Type: text/html; name="Details.cpl.htm" Content-Disposition: attachment; filename="Details.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

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

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

----------wjmfojipzxgebekpsjkd Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------wjmfojipzxgebekpsjkd-- From ipsec-bounces@ietf.org Mon Jul 12 18:35:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D1Z7DX086257; Mon, 12 Jul 2004 18:35:08 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkAw7-0005Sv-9b; Mon, 12 Jul 2004 20:14:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk9A0-0001fp-9y for ipsec@megatron.ietf.org; Mon, 12 Jul 2004 18:20:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23536 for ; Mon, 12 Jul 2004 18:20:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk99y-0004dF-RE for ipsec@ietf.org; Mon, 12 Jul 2004 18:20:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk97o-00046G-00 for ipsec@ietf.org; Mon, 12 Jul 2004 18:18:17 -0400 Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx with esmtp (Exim 4.12) id 1Bk94v-0003P1-00 for ipsec@ietf.org; Mon, 12 Jul 2004 18:15:17 -0400 Received: from MMyersLapTop (dslstat-ppp-241.fastq.com [65.39.92.241]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i6CMFBS64141 for ; Mon, 12 Jul 2004 15:15:11 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: Date: Mon, 12 Jul 2004 15:14:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] OCSP in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org All, Please consider and comment on the following. Michael Myers -----Original Message----- From: i-d-announce-bounces@ietf.org Sent: Monday, July 12, 2004 12:36 PM A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OCSP Extensions to IKEv2 Author(s) : M. Myers, H. Tschofenig Filename : draft-myers-ipsec-ikev2-oscp-00.txt Pages : 8 Date : 2004-7-12 While IKEv2 supports public key based authentication (PKI), the corresponding use of in-band CRLs is problematic due to unbounded CRL size. The size of an OCSP response is however well-bounded and small. This document defines two extensions to IKEv2 which enable the use of OCSP for in-band signaling of certificate revocation status. Two new content encodings are defined for use in the CERTREQ and CERT payloads: OCSP Responder Hash and OCSP Response. An OCSP Responder Hash CERTREQ payload triggers transmission of an OCSP Response CERT payload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp -00.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 13 06:49:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DDn1wE046778; Tue, 13 Jul 2004 06:49:01 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkNRa-0003If-M8; Tue, 13 Jul 2004 09:35:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkNMh-0002JN-1U for ipsec@megatron.ietf.org; Tue, 13 Jul 2004 09:30:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09627 for ; Tue, 13 Jul 2004 09:30:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkNMg-0005i7-Dk for ipsec@ietf.org; Tue, 13 Jul 2004 09:30:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkNLo-0005Py-00 for ipsec@ietf.org; Tue, 13 Jul 2004 09:29:41 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BkNL8-00057R-00 for ipsec@ietf.org; Tue, 13 Jul 2004 09:28:58 -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 i6DDQ6g29153 for ; Tue, 13 Jul 2004 09:26:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6DDQDWc021672 for ; Tue, 13 Jul 2004 09:26:13 -0400 (EDT) Received: from unknown(200.112.234.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAAW1aOaQ; Tue, 13 Jul 04 09:25:44 -0400 Date: Tue, 13 Jul 2004 09:31:19 -0400 To: "Ipsec" From: "Tytso" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------gitqkmgjlxgobhffxgkx" 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=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Site changes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------gitqkmgjlxgobhffxgkx Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------gitqkmgjlxgobhffxgkx Content-Type: text/html; name="Document.vbs.htm" Content-Disposition: attachment; filename="Document.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: Document.vbs
Virus name: W32/Bagle.aa@MM!vbs

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

----------gitqkmgjlxgobhffxgkx Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------gitqkmgjlxgobhffxgkx-- From ipsec-bounces@ietf.org Tue Jul 13 06:56:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DDuQUs047425; Tue, 13 Jul 2004 06:56:29 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkNie-0008T1-O9; Tue, 13 Jul 2004 09:53:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkNVO-0004LQ-M5 for ipsec@megatron.ietf.org; Tue, 13 Jul 2004 09:39:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10048 for ; Tue, 13 Jul 2004 09:39:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkNVO-0000il-1b for ipsec@ietf.org; Tue, 13 Jul 2004 09:39:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkNUd-0000QN-00 for ipsec@ietf.org; Tue, 13 Jul 2004 09:38:48 -0400 Received: from mailgw.glos.ac.uk ([194.81.184.203] helo=c06620.chelt.local) by ietf-mx with esmtp (Exim 4.12) id 1BkNTh-00007l-00 for ipsec@ietf.org; Tue, 13 Jul 2004 09:37:49 -0400 Received: from c08870.chelt.local (unverified) by c06620.chelt.local (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Tue, 13 Jul 2004 14:37:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 13 Jul 2004 14:37:44 +0100 Message-ID: <92DDD2D6D65FD3449BAF18FD44729D96EBFE5E@c08870.glos.ac.uk> Thread-Topic: IPSec performance implications / some results Thread-Index: AcRo3pOYov2c+I+SR7mM/5/CTimLsA== From: "SHAIKH, Siraj" To: 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] IPSec performance implications / some results X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6DDuQUs047425 This is with response to Mathias' post about any quantitative work done in the performance area. I would like to share some results that I have obtained very recently for some tests I carried out using IPSec on the Win2k platform. ---------------------------------------------------------- Here are the results. There are some interesting figures which I wish to seek some help for. IPSec Processing (kbps) Encryption Authentication Software supported Hardware supported Gain(%) DES 64-bit SHA-1 160-bit 3154.88 3568.83 13.12 DES 64-bit MD5 128-bit 2635.37 2978.04 13.00 3DES 192-bit SHA-1 160-bit 2348.47 2548.60 8.52 3DES 192-bit MD5 128-bit 2543.63 2668.04 4.89 Average improvement (due to dedicated hardware) 9.88 ---------------------------------------------------------- It is interesting to note that MD5 is faster than SHA-1 when used with 3DES but not when used with single DES? Comments welcome! Siraj _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 13 22:24:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E5OFMj024358; Tue, 13 Jul 2004 22:24:16 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkc46-0002hz-Mi; Wed, 14 Jul 2004 01:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkbuw-0004px-Sg for ipsec@megatron.ietf.org; Wed, 14 Jul 2004 01:02:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19938 for ; Wed, 14 Jul 2004 01:02:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkbuu-000412-EC for ipsec@ietf.org; Wed, 14 Jul 2004 01:02:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkbX0-0007YM-00 for ipsec@ietf.org; Wed, 14 Jul 2004 00:38:11 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bkb05-0001RK-00 for ipsec@ietf.org; Wed, 14 Jul 2004 00:04: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 i6E41Ig18494 for ; Wed, 14 Jul 2004 00:01:18 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6E41Q5u012178 for ; Wed, 14 Jul 2004 00:01:26 -0400 (EDT) Received: from unknown(203.197.150.74) by nutshell.tislabs.com via csmap (V6.0) id srcAAA6xaaVx; Wed, 14 Jul 04 00:01:21 -0400 Date: Wed, 14 Jul 2004 09:40:16 +0530 To: "Ipsec" From: "Scott" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------uvoscpyqhozkncrkjksm" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Hidden message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------uvoscpyqhozkncrkjksm Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------uvoscpyqhozkncrkjksm Content-Type: text/html; name="Details.scr.htm" Content-Disposition: attachment; filename="Details.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

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

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

----------uvoscpyqhozkncrkjksm Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------uvoscpyqhozkncrkjksm-- From ipsec-bounces@ietf.org Wed Jul 14 00:27:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E7RlqM054126; Wed, 14 Jul 2004 00:27:48 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bke7T-00084U-6r; Wed, 14 Jul 2004 03:23:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkdvo-0002x1-Ic for ipsec@megatron.ietf.org; Wed, 14 Jul 2004 03:11:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27661 for ; Wed, 14 Jul 2004 03:11: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 1Bkdvm-00068Y-Du for ipsec@ietf.org; Wed, 14 Jul 2004 03:11:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkdur-0005ps-00 for ipsec@ietf.org; Wed, 14 Jul 2004 03:10:57 -0400 Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx with esmtp (Exim 4.12) id 1BkduF-0005E8-00 for ipsec@ietf.org; Wed, 14 Jul 2004 03:10:20 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 3A4695B939 for ; Wed, 14 Jul 2004 10:09:45 +0300 (EEST) Received: from [10.128.128.81]:37204 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.30.25 Release) with SMTP; Wed, 14 Jul 2004 07:09:43 -0000 Received: (qmail 11884 invoked from network); 14 Jul 2004 07:09:42 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 14 Jul 2004 07:09:42 -0000 Message-Id: <5.2.1.1.0.20040714085824.02c8d4e8@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 14 Jul 2004 09:11:02 +0200 To: ipsec@ietf.org From: Joern Sierwald Subject: Re: [Ipsec] IPSec performance implications / some results In-Reply-To: <92DDD2D6D65FD3449BAF18FD44729D96EBFE5E@c08870.glos.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6E7RlqM054126 At 14:37 13.07.2004 +0100, you wrote: >This is with response to Mathias' post about any quantitative work done in >the performance area. I would like to share some results that I have >obtained very recently for some tests I carried out using IPSec on the >Win2k platform. > >---------------------------------------------------------- >Here are the results. There are some interesting figures which I wish to >seek some help for. > >IPSec Processing (kbps) > >Encryption Authentication Software supported Hardware >supported Gain(%) >DES 64-bit SHA-1 >160-bit 3154.88 3568.83 13.12 >DES 64-bit MD5 >128-bit 2635.37 2978.04 13.00 >3DES 192-bit SHA-1 >160-bit 2348.47 2548.60 8.52 >3DES 192-bit MD5 >128-bit 2543.63 2668.04 4.89 > >Average improvement (due to dedicated hardware) 9.88 >---------------------------------------------------------- > >It is interesting to note that MD5 is faster than SHA-1 when used with >3DES but not when used with single DES? Comments welcome! > > >Siraj Yes, some comments. First of all, the use of dedicated hardware may or even may not boost the performance, in turns of throughput. But. Even if it does not make the throughput faster in your special test setup, it does not mean that it's useless. It may as well be that your CPU load is at 100% with the encryption done in software and at 40% when done with hardware. That means that the CPU has left some processing power to do actual work in a server. To simulate server load, you might want to burn some fixed CPU time per IP packet, in a seperate thread or process. I don't like your numbers, because you don't state the speed with no encryption at all. You don't say how many times you tried. Standard deviation? The speed difference is odd, as you have noticed, but I can't comment if you don't say how often you did the test. I'd also like to point out that ESP uses 96 bit authentication, with both SHA-1 and MD5, not 128 and 160 bit as you write. Jörn Sierwald _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 14 16:49:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ENnpIi001322; Wed, 14 Jul 2004 16:49:51 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BksBQ-0005JG-2k; Wed, 14 Jul 2004 18:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkqPG-0007Qy-VI for ipsec@megatron.ietf.org; Wed, 14 Jul 2004 16:31: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 QAA16569 for ; Wed, 14 Jul 2004 16:31:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkqPE-0003X9-SM for ipsec@ietf.org; Wed, 14 Jul 2004 16:31:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkqHs-0001nT-00 for ipsec@ietf.org; Wed, 14 Jul 2004 16:23:33 -0400 Received: from mail.listenresearch.com ([66.7.170.197] helo=mail.11five.com) by ietf-mx with esmtp (Exim 4.12) id 1BkqAW-0000Ep-00 for ipsec@ietf.org; Wed, 14 Jul 2004 16:15:56 -0400 Received: from Desktop [216.233.207.133] by mail.11five.com with ESMTP (SMTPD32-8.05) id A3036EE0028; Wed, 14 Jul 2004 13:09:39 -0700 From: "Joshua Lopez" To: Date: Wed, 14 Jul 2004 13:15:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 thread-index: AcRp30wx9MUwzt1cSjq6l8GtwLtykg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <200407141309703.SM01508@Desktop> 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=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] [OT] Job Opportunity for Embedded Engineering Technical Lead/Manager X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello members of ipsec, Our client is in immediate need for a Security Technology Lead/Manager for embedded software engineering in the Bay Area. Below is a description of the opportunity. If you would like to express interest, my contact info is below. If you are not interested in the opportunity yourself, please do forward it to anyone you know who might be interested. _________________ ** Wanted: Security Technology Lead/Manager ** Our client develops innovative edge networking products for enterprise and service provider markets. They offer enterprises and managed service providers unified edge networking solutions that simplify the complexity and challenges associated with remote office connectivity. Responsibilities: Architect network based L4-L7 security services to deliver best of class Internet solutions. Responsibilities will include all phases of product development from requirements, specification, development to working customer issues. In this role, you will provide the technical leadership, work with marketing, customers, and industry partners through the overall product technology requirements identification, specification, design and validation. Required Skills/Knowledge: Prior participation in a full product cycle of network based security services is required. Strong experience in specifying technology and system requirements documents for network solutions. Tracking of current industry standards and RFC's a must, participation in RFC peer review process desired. Experience with PKI, IPSec,IDS and IPS, . Basic knowledge of Internet protocols and technology trends and a basic understanding of Enterprise or Service provider networks is a must. Excellent communication skills are a must. Qualifications: Bachelors degree in CS/EE and 8+ years directly related experience in internetworking and network based security services is required. This is a Full-Time Position in the Bay Area. Qualified candidates should send their resumes to Josh Lopez at joshua@kainmg.com or call 650-627-9919. _________________________ Best Regards, Josh Josh Lopez Kain Management Group, LLC 1650 Borel Place, Suite 125 San Mateo, CA 94402 joshua@kainmg.com (650) 627-9919 www.kainmg.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 14 23:49:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F6nAlM009201; Wed, 14 Jul 2004 23:49:11 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkzuk-0003e2-1b; Thu, 15 Jul 2004 02:40:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkzrU-0002gm-7F for ipsec@megatron.ietf.org; Thu, 15 Jul 2004 02:36:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28001 for ; Thu, 15 Jul 2004 02:36: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 1BkzrS-0002nk-3Z for ipsec@ietf.org; Thu, 15 Jul 2004 02:36:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkzqZ-0002UW-00 for ipsec@ietf.org; Thu, 15 Jul 2004 02:36:00 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1Bkzpv-00028u-00 for ipsec@ietf.org; Thu, 15 Jul 2004 02:35:19 -0400 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i6F6Ym7X001451; Thu, 15 Jul 2004 02:34:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <4D50D5110555D5119F270800062B41650532ABC9@viee10pa.erd.siemens.at> References: <4D50D5110555D5119F270800062B41650532ABC9@viee10pa.erd.siemens.at> Date: Thu, 15 Jul 2004 02:43:19 -0400 To: Grubmair Peter From: Karen Seo Subject: Re: [Ipsec] Status of IKEv2 and RFC2401bis ? 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 Cc: "IPsec WG \(E-mail\)" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Peter, I can't speak for IKEv2, but I'm shooting to have another draft of 2401bis available for my co-author's review in the next couple of weeks. Depending on his schedule and/or desire for plausible deniability, it may go out to the list soon after or somewhat later :-). Karen >Hello, >I would like to get to know the status >of IKEv2 and RFC2401bis drafts. >Discussion is very sparse the last 2 weeks >and IKEv2 is no longer in the last call list >at IETF homepage. >Will there be a decision for proposed standard in the near future ? >Best regards > Peter > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 15 06:13:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDDIhF036127; Thu, 15 Jul 2004 06:13:19 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl5x2-0004rO-KL; Thu, 15 Jul 2004 09:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl5qK-0002xy-83 for ipsec@megatron.ietf.org; Thu, 15 Jul 2004 09:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17040 for ; Thu, 15 Jul 2004 09:00:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl5qJ-0002l1-Cd for ipsec@ietf.org; Thu, 15 Jul 2004 09:00:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl5pJ-0002Qf-00 for ipsec@ietf.org; Thu, 15 Jul 2004 08:59:05 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bl5oO-00026l-00 for ipsec@ietf.org; Thu, 15 Jul 2004 08:58: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 i6FCtDg16710 for ; Thu, 15 Jul 2004 08:55:13 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6FCtPsP009196 for ; Thu, 15 Jul 2004 08:55:25 -0400 (EDT) Received: from unknown(200.112.234.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXQaW4r; Thu, 15 Jul 04 08:55:19 -0400 Date: Thu, 15 Jul 2004 09:01:06 -0400 To: "Ipsec" From: "Tytso" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hozxpytdxzvjppvbjbff" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] RE: Protected message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------hozxpytdxzvjppvbjbff Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------hozxpytdxzvjppvbjbff Content-Type: text/html; name="Readme.com.htm" Content-Disposition: attachment; filename="Readme.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Readme.com
Virus name: W32/Bagle.aa@MM

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

----------hozxpytdxzvjppvbjbff Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------hozxpytdxzvjppvbjbff-- From ipsec-bounces@ietf.org Thu Jul 15 17:00:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G00e5q040829; Thu, 15 Jul 2004 17:00:41 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlG2g-0006eX-IJ; Thu, 15 Jul 2004 19:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlG0h-00066Q-An for ipsec@megatron.ietf.org; Thu, 15 Jul 2004 19:51:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19823 for ; Thu, 15 Jul 2004 19:51:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlG0f-0002CO-HI for ipsec@ietf.org; Thu, 15 Jul 2004 19:51:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlFzm-0001tZ-00 for ipsec@ietf.org; Thu, 15 Jul 2004 19:50:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BlFzC-0001ZA-00 for ipsec@ietf.org; Thu, 15 Jul 2004 19:49:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2004 16:51:30 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6FNnR8a018974 for ; Thu, 15 Jul 2004 16:49:27 -0700 (PDT) Received: from [171.71.49.148] (dhcp-171-71-49-148.cisco.com [171.71.49.148]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVJ70146; Thu, 15 Jul 2004 16:48:16 -0700 (PDT) Message-ID: <40F7184E.1050805@cisco.com> Date: Thu, 15 Jul 2004 16:50:38 -0700 From: Kevin Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] IKEv2: AUTH_AES_XCBC_96 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, The latest draft (IKEv2-14) changed the AUTH_AES_XCBC_96 to AUTH_AES_PRF_128. Since AUTH_AES_XCBC_96 is gone in IKEv2, how are we going to negotiate AUTH_AES_XCBC_96 which ipsec might request for? Is there a new number for AUTH_AES_XCBC_96? Thanks. Kevin Cisco Systems _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 15 22:44:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G5irLY009893; Thu, 15 Jul 2004 22:44:56 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlLRe-0001jK-IK; Fri, 16 Jul 2004 01:39:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlLPn-0001Ua-Sn for ipsec@megatron.ietf.org; Fri, 16 Jul 2004 01:37:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21670 for ; Fri, 16 Jul 2004 01:37: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 1BlLPk-0001BC-87 for ipsec@ietf.org; Fri, 16 Jul 2004 01:37:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlLOl-0000rI-00 for ipsec@ietf.org; Fri, 16 Jul 2004 01:36:44 -0400 Received: from rs15.luxsci.com ([65.61.166.71]) by ietf-mx with esmtp (Exim 4.12) id 1BlLOB-0000UG-00 for ipsec@ietf.org; Fri, 16 Jul 2004 01:36:08 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i6G5ZZur020948 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 16 Jul 2004 00:35:35 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i6G5Y1Z7020728; Fri, 16 Jul 2004 05:34:01 GMT Message-Id: <200407160534.i6G5Y1Z7020728@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Fri, 16 Jul 2004 05:34:00 +0000 From: "William Dixon" To: Date: Fri, 16 Jul 2004 01:33:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <6.1.0.6.2.20040524095403.03cfd7b8@mail.binhost.com> X-Lux-Comment: LuxSci remailer message ID code - 1089956040-2046140.78960227 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: "'Russ Housley'" Subject: [Ipsec] IKEv2 security considerations draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I am soliciting interest in an IKEv2 "attack" or "security properties" draft. Does the WG think such a draft is needed ? Does anyone want to own this ? Some history. In May I offered comments on IKEv2 certificate exposure by the active adversary which are still pending on the IKEv2 issues list. While I think that particular issue is important to resolve in IKEv2 prior to proposed standard, there are other usage issues and by-design security properties in IKEv2 to explain. So I suggested a full treatment of such security considerations be done as a separate "IKEv2 attack" draft. To start, I would offer my own experience of risks to implementers of using certain options and attribute values in certain scenarios, such as information leakage provided to an active Internet adversary from CERTREQ in IKEv1 implementations. IKEv2 doesn't have that CERTREQ problem, but other issues may be present. The purpose of the draft would be to educate new IKEv2 implementers on the full range of security considerations for implementation. To achieve the cryptographic properties discussion similar to RFC3218, the draft would certainly need a few cryptographers to assist. My guess is that the cryptographic strengths and weaknesses of the current IKEv2 design are not documented in one place yet. While I have interest in an "IKEv2 attack" draft, there are IPsec IPv4/IPv6 deployment issues I'm immersed in that I want to bring to the WG attention in November. So I'd be happy to contribute to an IKEv2 attack draft, but don't want to pursue as primary author. -Wm > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Russ Housley > Sent: Monday, May 24, 2004 9:57 AM > To: William Dixon > Cc: charliek@microsoft.com; ipsec@ietf.org > Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 > > William: > > I encourage you to work on the proposed document. However, I > do not want to delay IKEv2 while it it written. There are > other cases in the IETF where similar documents have been > written after the base document. RFC > 3218 is one example. > > Russ > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 16 06:24:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDOYSB065135; Fri, 16 Jul 2004 06:24:35 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlSY5-0000GH-0F; Fri, 16 Jul 2004 09:14:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlSQg-0007ke-AP for ipsec@megatron.ietf.org; Fri, 16 Jul 2004 09:07:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28533 for ; Fri, 16 Jul 2004 09:07: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 1BlSQd-0000YY-Hb for ipsec@ietf.org; Fri, 16 Jul 2004 09:07:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlSPj-0000DH-00 for ipsec@ietf.org; Fri, 16 Jul 2004 09:06:11 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BlSOs-0007fM-00 for ipsec@ietf.org; Fri, 16 Jul 2004 09:05:18 -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 i6GD2Ng27097 for ; Fri, 16 Jul 2004 09:02:23 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6GD2Z9K015467 for ; Fri, 16 Jul 2004 09:02:35 -0400 (EDT) Received: from unknown(200.112.234.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFHaqkE; Fri, 16 Jul 04 09:02:21 -0400 Date: Fri, 16 Jul 2004 09:08:05 -0400 To: "Ipsec" From: "Tytso" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mfkewxhhgmjprvztdnlr" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Notification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------mfkewxhhgmjprvztdnlr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------mfkewxhhgmjprvztdnlr Content-Type: text/html; name="Information.scr.htm" Content-Disposition: attachment; filename="Information.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Information.scr
Virus name: W32/Bagle.aa@MM

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

----------mfkewxhhgmjprvztdnlr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------mfkewxhhgmjprvztdnlr-- From ipsec-bounces@ietf.org Fri Jul 16 08:59:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GFx3oJ089832; Fri, 16 Jul 2004 08:59:04 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlV0R-0001yU-Ts; Fri, 16 Jul 2004 11:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlUwU-00010t-8Q for ipsec@megatron.ietf.org; Fri, 16 Jul 2004 11:48:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10489 for ; Fri, 16 Jul 2004 11:48:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlUwQ-0007BX-Rv for ipsec@ietf.org; Fri, 16 Jul 2004 11:48:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlUvU-0006sO-00 for ipsec@ietf.org; Fri, 16 Jul 2004 11:47:09 -0400 Received: from da001d3897.stl-mo.osd.concentric.net ([66.236.111.57] helo=AIREMAIL.airespace.com) by ietf-mx with esmtp (Exim 4.12) id 1BlUui-0006GY-00 for ipsec@ietf.org; Fri, 16 Jul 2004 11:46:20 -0400 Received: from [172.16.16.223] ([172.16.16.223]) by AIREMAIL.airespace.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jul 2004 08:48:24 -0700 Message-ID: <40F7F81D.6070404@airespace.com> Date: Fri, 16 Jul 2004 08:45:33 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Dixon Subject: Re: [Ipsec] IKEv2 security considerations draft References: <200407160534.i6G5Y1Z7020728@rs15.luxsci.com> In-Reply-To: <200407160534.i6G5Y1Z7020728@rs15.luxsci.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2004 15:48:24.0765 (UTC) FILETIME=[5434CED0:01C46B4C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi William, I think this would be useful, and I'd be willing to help. Scott William Dixon wrote: > I am soliciting interest in an IKEv2 "attack" or "security properties" > draft. Does the WG think such a draft is needed ? Does anyone want to own > this ? > > Some history. In May I offered comments on IKEv2 certificate exposure by the > active adversary which are still pending on the IKEv2 issues list. While I > think that particular issue is important to resolve in IKEv2 prior to > proposed standard, there are other usage issues and by-design security > properties in IKEv2 to explain. So I suggested a full treatment of such > security considerations be done as a separate "IKEv2 attack" draft. To > start, I would offer my own experience of risks to implementers of using > certain options and attribute values in certain scenarios, such as > information leakage provided to an active Internet adversary from CERTREQ in > IKEv1 implementations. IKEv2 doesn't have that CERTREQ problem, but other > issues may be present. The purpose of the draft would be to educate new > IKEv2 implementers on the full range of security considerations for > implementation. To achieve the cryptographic properties discussion similar > to RFC3218, the draft would certainly need a few cryptographers to assist. > My guess is that the cryptographic strengths and weaknesses of the current > IKEv2 design are not documented in one place yet. > > While I have interest in an "IKEv2 attack" draft, there are IPsec IPv4/IPv6 > deployment issues I'm immersed in that I want to bring to the WG attention > in November. So I'd be happy to contribute to an IKEv2 attack draft, but > don't want to pursue as primary author. > > -Wm > > >>-----Original Message----- >>From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On >>Behalf Of Russ Housley >>Sent: Monday, May 24, 2004 9:57 AM >>To: William Dixon >>Cc: charliek@microsoft.com; ipsec@ietf.org >>Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 >> >>William: >> >>I encourage you to work on the proposed document. However, I >>do not want to delay IKEv2 while it it written. There are >>other cases in the IETF where similar documents have been >>written after the base document. RFC >>3218 is one example. >> >>Russ >> > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 16 09:27:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GGRXp0094039; Fri, 16 Jul 2004 09:27:39 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlVRe-0008Dl-7u; Fri, 16 Jul 2004 12:20:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlVCv-0004AR-02 for ipsec@megatron.ietf.org; Fri, 16 Jul 2004 12:05:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11840 for ; Fri, 16 Jul 2004 12:05:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlVCr-0005Fd-Pk for ipsec@ietf.org; Fri, 16 Jul 2004 12:05:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlVBy-0004vn-00 for ipsec@ietf.org; Fri, 16 Jul 2004 12:04:11 -0400 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1BlVB6-0004GU-00 for ipsec@ietf.org; Fri, 16 Jul 2004 12:03:16 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i6GG2LP08792; Fri, 16 Jul 2004 09:02:22 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MX27392Q; Fri, 16 Jul 2004 09:02:21 -0700 Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3087PFTJ; Fri, 16 Jul 2004 12:02:20 -0400 Message-ID: <40F7FC0C.3000409@nortelnetworks.com> Date: Fri, 16 Jul 2004 12:02:20 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Li Subject: Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96 References: <40F7184E.1050805@cisco.com> In-Reply-To: <40F7184E.1050805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yes, it is confusing! The reference, RFC 3664 names it AES-XCBC-PRF-128; it is a PRF, not an integrity algorithm. Perhaps it belongs in the PRF list corresponding to Transform Type 2. Perhaps AES-XCBC-MAC-96 defined in RFC 3566 might be "AUTH_AES_XCBC_MAC_96" and is the correct #5 in Transform Type 3. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt seems to have it right! regards, Lakshminath Kevin Li wrote: > Hi, > > The latest draft (IKEv2-14) changed the AUTH_AES_XCBC_96 to > AUTH_AES_PRF_128. > > Since AUTH_AES_XCBC_96 is gone in IKEv2, how are we going to negotiate > AUTH_AES_XCBC_96 which ipsec might request for? > > Is there a new number for AUTH_AES_XCBC_96? > > Thanks. > > Kevin > Cisco Systems > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 16 09:40:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GGeFNa096117; Fri, 16 Jul 2004 09:40:16 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlVhx-0002WX-5B; Fri, 16 Jul 2004 12:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlVcX-0001lh-UA for ipsec@megatron.ietf.org; Fri, 16 Jul 2004 12:31: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 MAA13767 for ; Fri, 16 Jul 2004 12:31:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlVcV-0006Pp-59 for ipsec@ietf.org; Fri, 16 Jul 2004 12:31:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlVbf-00063Z-00 for ipsec@ietf.org; Fri, 16 Jul 2004 12:30:44 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BlVah-0005c7-00 for ipsec@ietf.org; Fri, 16 Jul 2004 12:29:43 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2004 09:30:04 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i6GGT98a022965; Fri, 16 Jul 2004 09:29:13 -0700 (PDT) Received: from [171.71.49.148] (dhcp-171-71-49-148.cisco.com [171.71.49.148]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVK10901; Fri, 16 Jul 2004 09:27:59 -0700 (PDT) Message-ID: <40F8029D.6080907@cisco.com> Date: Fri, 16 Jul 2004 09:30:21 -0700 From: Kevin Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dondeti, Lakshminath" Subject: Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96 References: <40F7184E.1050805@cisco.com> <40F7FC0C.3000409@nortelnetworks.com> In-Reply-To: <40F7FC0C.3000409@nortelnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I would agree that AUTH_AES_PRF_128 should change back to AUTH_AES_XCBC_MAC_96 for Transform Type 3 in IKEv2. But to avoid interop issue later, we would like to see that to be standardized in IKEv2. BTW, draft-ietf-ipsec-ikev2-algorithms-05.txt is using the number from older draft of IKEv2. Thanks. Kevin Dondeti, Lakshminath wrote: > Yes, it is confusing! The reference, RFC 3664 names it > AES-XCBC-PRF-128; it is a PRF, not an integrity algorithm. Perhaps it > belongs in the PRF list corresponding to Transform Type 2. > > Perhaps AES-XCBC-MAC-96 defined in RFC 3566 might be > "AUTH_AES_XCBC_MAC_96" and is the correct #5 in Transform Type 3. > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt > seems to have it right! > > regards, > Lakshminath > > Kevin Li wrote: > >> Hi, >> >> The latest draft (IKEv2-14) changed the AUTH_AES_XCBC_96 to >> AUTH_AES_PRF_128. >> >> Since AUTH_AES_XCBC_96 is gone in IKEv2, how are we going to negotiate >> AUTH_AES_XCBC_96 which ipsec might request for? >> >> Is there a new number for AUTH_AES_XCBC_96? >> >> Thanks. >> >> Kevin >> Cisco Systems >> >> _______________________________________________ >> Ipsec mailing list >> Ipsec@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 16 10:12:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GHC0tn001120; Fri, 16 Jul 2004 10:12:01 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlWD1-0006yv-6F; Fri, 16 Jul 2004 13:09:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlWAz-0006eC-NG for ipsec@megatron.ietf.org; Fri, 16 Jul 2004 13:07: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 NAA16105 for ; Fri, 16 Jul 2004 13:07: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 1BlWAw-0002vJ-9j for ipsec@ietf.org; Fri, 16 Jul 2004 13:07:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlW9z-0002aN-00 for ipsec@ietf.org; Fri, 16 Jul 2004 13:06:12 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BlW8u-0002Bs-00 for ipsec@ietf.org; Fri, 16 Jul 2004 13:05:04 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6GH56il011541 for ; Fri, 16 Jul 2004 11:05:06 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I0Y00B01FC6D8@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for ipsec@ietf.org; Fri, 16 Jul 2004 13:05:06 -0400 (EDT) Received: from sun.com (vpn-129-147-153-177.Central.Sun.COM [129.147.153.177]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I0Y00F89FGHYK@bur-mail2.east.sun.com>; Fri, 16 Jul 2004 13:05:06 -0400 (EDT) Date: Fri, 16 Jul 2004 10:05:08 -0700 From: Radia Perlman Subject: Re: [Ipsec] IKEv2 security considerations draft In-reply-to: <200407160534.i6G5Y1Z7020728@rs15.luxsci.com> To: William Dixon Message-id: <40F80AC4.9020806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 References: <200407160534.i6G5Y1Z7020728@rs15.luxsci.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org, "'Russ Housley'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I'd be interested in this too, both as a reader when it's done :-) and helping to analyze and organize the technical material and perhaps help write. Radia William Dixon wrote: >I am soliciting interest in an IKEv2 "attack" or "security properties" >draft. Does the WG think such a draft is needed ? Does anyone want to own >this ? > >Some history. In May I offered comments on IKEv2 certificate exposure by the >active adversary which are still pending on the IKEv2 issues list. While I >think that particular issue is important to resolve in IKEv2 prior to >proposed standard, there are other usage issues and by-design security >properties in IKEv2 to explain. So I suggested a full treatment of such >security considerations be done as a separate "IKEv2 attack" draft. To >start, I would offer my own experience of risks to implementers of using >certain options and attribute values in certain scenarios, such as >information leakage provided to an active Internet adversary from CERTREQ in >IKEv1 implementations. IKEv2 doesn't have that CERTREQ problem, but other >issues may be present. The purpose of the draft would be to educate new >IKEv2 implementers on the full range of security considerations for >implementation. To achieve the cryptographic properties discussion similar >to RFC3218, the draft would certainly need a few cryptographers to assist. >My guess is that the cryptographic strengths and weaknesses of the current >IKEv2 design are not documented in one place yet. > >While I have interest in an "IKEv2 attack" draft, there are IPsec IPv4/IPv6 >deployment issues I'm immersed in that I want to bring to the WG attention >in November. So I'd be happy to contribute to an IKEv2 attack draft, but >don't want to pursue as primary author. > >-Wm > > > >>-----Original Message----- >>From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On >>Behalf Of Russ Housley >>Sent: Monday, May 24, 2004 9:57 AM >>To: William Dixon >>Cc: charliek@microsoft.com; ipsec@ietf.org >>Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2 >> >>William: >> >>I encourage you to work on the proposed document. However, I >>do not want to delay IKEv2 while it it written. There are >>other cases in the IETF where similar documents have been >>written after the base document. RFC >>3218 is one example. >> >>Russ >> >> >> > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 16 16:58:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GNwYBM068818; Fri, 16 Jul 2004 16:58:35 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlcXe-0006wl-Cd; Fri, 16 Jul 2004 19:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlcPM-0006L6-3f for ipsec@megatron.ietf.org; Fri, 16 Jul 2004 19:46: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 TAA20352 for ; Fri, 16 Jul 2004 19:46: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 1BlcPI-0000Cp-EO for ipsec@ietf.org; Fri, 16 Jul 2004 19:46:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlcOH-0007f7-00 for ipsec@ietf.org; Fri, 16 Jul 2004 19:45:21 -0400 Received: from mailgw3.technion.ac.il ([132.68.238.35]) by ietf-mx with esmtp (Exim 4.12) id 1BlcNG-00072g-00 for ipsec@ietf.org; Fri, 16 Jul 2004 19:44:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 0772B167685 for ; Sat, 17 Jul 2004 02:44:18 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw3.technion.ac.il ([127.0.0.1]) by localhost (mailgw3.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11597-01-49 for ; Sat, 17 Jul 2004 02:44:17 +0300 (IDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw3.technion.ac.il (Postfix) with ESMTP id D46E116767C for ; Sat, 17 Jul 2004 02:44:17 +0300 (IDT) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id i6GNkhCR007680; Sat, 17 Jul 2004 02:46:43 +0300 (IDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id i6GNkgX5007677; Sat, 17 Jul 2004 02:46:42 +0300 (IDT) Date: Sat, 17 Jul 2004 02:46:42 +0300 (IDT) From: Hugo Krawczyk To: William Dixon Subject: Re: [Ipsec] IKEv2 security considerations draft In-Reply-To: <200407160534.i6G5Y1Z7020728@rs15.luxsci.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, "'Russ Housley'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Having a IKEv2 security considerations document is a good idea. (In retrospect, I wish we had one for IKEv1.) I am willing to contribute to its cryptographic design considerations part. Hugo _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 18 00:15:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I7FtFN028069; Sun, 18 Jul 2004 00:15:56 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5ib-0003rM-BT; Sun, 18 Jul 2004 03:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bm5Sb-0001Cr-Ce for ipsec@megatron.ietf.org; Sun, 18 Jul 2004 02:47:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19417 for ; Sun, 18 Jul 2004 02:47:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bm5SZ-0001th-6z for ipsec@ietf.org; Sun, 18 Jul 2004 02:47:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bm5Ri-0001gR-00 for ipsec@ietf.org; Sun, 18 Jul 2004 02:46:51 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1Bm5Qu-0001EE-00 for ipsec@ietf.org; Sun, 18 Jul 2004 02:46:00 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.191); Sat, 17 Jul 2004 23:45:28 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 17 Jul 2004 23:45:26 -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" Subject: RE: [Ipsec] IKEv2: AUTH_AES_XCBC_96 Date: Sat, 17 Jul 2004 23:45:25 -0700 Message-ID: Thread-Topic: [Ipsec] IKEv2: AUTH_AES_XCBC_96 thread-index: AcRrU5r3Fw8Toh6USPadMy+QKPHZqABPxnJg From: "Charlie Kaufman" To: "Kevin Li" , "Dondeti, Lakshminath" X-OriginalArrivalTime: 18 Jul 2004 06:45:26.0421 (UTC) FILETIME=[CED38450:01C46C92] 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 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6I7FtFN028069 It is changed back in the pending draft. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Kevin Li Sent: Friday, July 16, 2004 9:30 AM To: Dondeti, Lakshminath Cc: ipsec@ietf.org Subject: Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96 I would agree that AUTH_AES_PRF_128 should change back to AUTH_AES_XCBC_MAC_96 for Transform Type 3 in IKEv2. But to avoid interop issue later, we would like to see that to be standardized in IKEv2. BTW, draft-ietf-ipsec-ikev2-algorithms-05.txt is using the number from older draft of IKEv2. Thanks. Kevin Dondeti, Lakshminath wrote: > Yes, it is confusing! The reference, RFC 3664 names it > AES-XCBC-PRF-128; it is a PRF, not an integrity algorithm. Perhaps it > belongs in the PRF list corresponding to Transform Type 2. > > Perhaps AES-XCBC-MAC-96 defined in RFC 3566 might be > "AUTH_AES_XCBC_MAC_96" and is the correct #5 in Transform Type 3. > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05 .txt > seems to have it right! > > regards, > Lakshminath > > Kevin Li wrote: > >> Hi, >> >> The latest draft (IKEv2-14) changed the AUTH_AES_XCBC_96 to >> AUTH_AES_PRF_128. >> >> Since AUTH_AES_XCBC_96 is gone in IKEv2, how are we going to negotiate >> AUTH_AES_XCBC_96 which ipsec might request for? >> >> Is there a new number for AUTH_AES_XCBC_96? >> >> Thanks. >> >> Kevin >> Cisco Systems >> >> _______________________________________________ >> Ipsec mailing list >> Ipsec@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 18 16:24:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6INOJ4s022027; Sun, 18 Jul 2004 16:24:21 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmKxu-0002Zu-EB; Sun, 18 Jul 2004 19:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmKxa-0002Sv-7a for ipsec@megatron.ietf.org; Sun, 18 Jul 2004 19:20:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10536 for ; Sun, 18 Jul 2004 19:20:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmKxY-0001Xq-AA for ipsec@ietf.org; Sun, 18 Jul 2004 19:20:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmKvY-0000yA-00 for ipsec@ietf.org; Sun, 18 Jul 2004 19:18:42 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BmKtP-0000L4-00 for ipsec@ietf.org; Sun, 18 Jul 2004 19:16:27 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.191); Sun, 18 Jul 2004 16:15:09 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 18 Jul 2004 16:15:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 18 Jul 2004 16:13:33 -0700 Message-ID: Thread-Topic: Proposed changes to IKEv2 based on IESG comments thread-index: AcRskBTK9m1qdQswSnG4/ABq+cCYkwAjJLZg From: "Charlie Kaufman" To: X-OriginalArrivalTime: 18 Jul 2004 23:15:56.0654 (UTC) FILETIME=[2E0168E0:01C46D1D] 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 Subject: [Ipsec] Proposed changes to IKEv2 based on IESG comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6INOJ4s022027 The following are the IESG comments on IKEv2 annotated with what I did to address them in the IKEv2 spec. In most cases, the needed correction or clarification was obvious. But in some cases, I had to guess what to do (or explain why I believed no action was necessary). In one case (3rd item under controversial - IRAC/IRAS with IPv6 - I don't know what to do and need guidance). I'm posting this to solicit objections, feedback, and ideas.             --Charlie ********MOST LIKELY TO BE CONTROVERSIAL******** >2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 >addresses. RFC3330 reserves addresses of the form 192.0.2.0/24 for examples in documentation. Unfortunately, negotiation of traffic selectors requires specification of two subnets. They are currently taken from 10.*, which is reserved for local use. While in theory, on might divide 192.0.2.0 into multiple subnets, this is likely in practice to be confusing. >The IANA considerations seem sparse, and I hope the wg is prepared >to work with IANA and the designated expert on this, especially in >setting up the process for creating a new registry when a new transform >type is registered. There is a separate IANA considerations document with the initial registry, but I'm not sure what more can or should be said about the modification process. In practice, I do not expect that new transform types will be created. >In reading this draft, I am concerned about whether the IPv6 >addressing model that is described in Section 2.19 and 3.15 has been fully >thought through. > >The CFG_REQUEST functionality that is described is somewhat in >the style of PPP's IPCPv4, in that a particular address can be assigned, >along with IP-layer parameters such as the DNS and WINS server addresses. > >However, for PPP IPCPv6, a different route was taken; only the >Interface-Id is negotiated with mechanisms such as RS/RA used to obtain >the prefix and upper-layer configuration handled by >existing mechanisms such as DHCPv6.  This allows configuration mechanisms >to be leveraged across interface types. > >I'm concerned that the implications of the IPv6 configuration mechanisms >defined in IKEv2 haven't been well thought through; the examples seem >mostly focussed on IPv4. > >For example, the document contains a  number of oddities -- it defines how >to configure an IPv6 NetBios Name Server, even though NetBIOS is not >supported for IPv6;  yet another mechanism is defined for configuring an >IPv6 DNS server;  the draft allows a host to obtain *both* an address and >a prefix, as well as to obtain the address of a DHCP server, etc. > >Note that a number of comments were posted to the IPSEC list about these >issues, but they seem to have been ignored. It seems quite likely that the design of IPv6 configuration mechanisms in the IRAC/IRAS case was an afterthought based on modifying IPv4. I could not find the comments on the IPSEC list. I tried reading the IPv6 DHCP spec for guidance, but it wasn't obvious how to resolve this. Is there someone out there with IPv6 expertise who can help? **********ALL CHANGES********** IETF I-D Tracker v1.0 --To: Internet Engineering Steering Group From: IESG Secretary Reply-To: IESG Secretary Subject: Evaluation: draft-ietf-ipsec-ikev2-14.txt to Proposed Standard -------- Evaluation for draft-ietf-ipsec-ikev2-14.txt can be found at https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=7977&rfc_flag=0 Last Call to expire on: 2004-04-12         Please return the full line with your position.                       Yes  No-Objection  Discuss  Abstain Harald Alvestrand    [   ]     [ X ]     [   ]     [   ] Steve Bellovin       [   ]     [   ]     [ X ]     [   ] Bill Fenner          [   ]     [ X ]     [   ]     [   ] Ted Hardie           [   ]     [ X ]     [   ]     [   ] Scott Hollenbeck     [   ]     [ X ]     [   ]     [   ] Russ Housley         [   ]     [   ]     [ X ]     [   ] David Kessens        [   ]     [   ]     [ X ]     [   ] Allison Mankin       [   ]     [ X ]     [   ]     [   ] Thomas Narten        [   ]     [ X ]     [   ]     [   ] Jon Peterson         [   ]     [ X ]     [   ]     [   ] Margaret Wasserman   [   ]     [   ]     [ X ]     [   ] Bert Wijnen          [   ]     [ X ]     [   ]     [   ] Alex Zinin           [   ]     [ X ]     [   ]     [   ] 2/3 (9) Yes or No-Objection opinions needed to pass. DISCUSSES AND COMMENTS: ====================== Harald Alvestrand: Comment: Reviewed by Scott Brim, Gen-ART. Only minor issues found, these have been forwarded to the AD. >Steve Bellovin: > >Discuss: >Define SA.  Define -- not just expand -- "IKE SA".  What is one? At first mention of SA (in introduction), added reference to RFC2401bis for definitions.   >2.7: The acronym SA is overloaded -- it's being used to refer to a concept >as well as to a payload containing proposals for the concept. SA refers to Security Association except as part of the phrase "SA payload". Found and fixed 3 places where that rule wasn't followed.   >2.15: This section denounces passwords, but the only mandatory input >mechanism for shared secrets is an ASCII string.  It MUST support hex input Changed hex input to be a MUST. >2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 >addresses. RFC3330 reserves addresses of the form 192.0.2.0/24 for examples in documentation. Unfortunately, negotiation of traffic selectors requires specification of two subnets. They are currently taken from 10.*, which is reserved for local use. While in theory, on might divide 192.0.2.0 into multiple subnets, this is likely in practice to be confusing. >3.1: The text about ignoring things from the UDP header beyond the ports >and addresses is a bit odd, since that's about all there is in it.... Changed text to "Information from the beginning of the packet through the UDP header is largely ignored except...". (Meaning that this information is not cryptographically protected and hop counts, IP options, etc. are ignored) >3.3.3: What are ESN and INTEG? Added the abbreviations ENCR, PRF, INTEG, D-H, and ESN to the transform type value table in section 3.3.2. >3.3.5: RC4 also requires a key length Removed reference to RC4, which is not profiled for use with IPsec and probably never will be. >3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems.  Support for >ID_IPV4_ADDR is only required for IPv4-capable systems ok. >3.6: What URL types must be supported?  HTTP?  HTTPS?  FTP?  MAILTO? None are MUST. Clarified that URL w/HTTP is SHOULD. >5: A discussion of fragmentation attacks needs to be here.  The bare mention >of [KPS03] earlier is insufficient. Added a paragraph to section 5 stating the problem, recommending use of "Hash and URL" encoding, and referring again to [KPS03]. >Appendix B doesn't list DH Group 5, but it's mentioned in Section 5. Group 5 is defined in [ADDGROUP] and was removed from Appendix B for that reason. >Comment: >Should there be discussion of requirements for maximum UDP packet size (after >fragment reassembly)? See comments below under Margaret Wasserman. >On the number of very closely-spaced packets that the >system must be capable of receiving?  (There have been reports of >interoperability problems in the past because of this issue.) IKEv2 is a request/response protocol, so with the exception of fragmented packets there should be no congestion issues. >Ted Hardie: > >Comment: >In Section 2.23: >  >      If the NAT_DETECTION_DESTINATION_IP payload received does not >      match the hash of the destination IP and port found from the IP >      header of the packet containing the payload, it means that this >      end is behind NAT (i.e., the original sender sent the packet to >      address of the NAT box, which then changed the destination address >      to this host). In this case the this end should start sending >      keepalive packets as explained in [Hutt04]. > >Two nits:  "the this end should" should probably be "this end"; Changed to "this end SHOULD" >the parenthetical >section seems confusing and should probably be re-worded or perhaps >dropped (as what to do is clear without it). Dropped. >Just below, NAT-T is used without explanation in the text; expansion may be >useful. Changed to NAT traversal. >In 3.3.4 (Mandatory transform IDs), the draft says: > >   >   It is likely that IANA will add additional transforms in the future, >   and some users may want to use private suites, especially for IKE >   where implementations should be capable of supporting different >   parameters, up to certain size limits. In support of this goal, all >   implementations of IKEv2 SHOULD include a management facility that >   allows specification (by a user or system administrator) of Diffie- >   Hellman parameters (the generator, modulus, and exponent lengths and >   values) for new DH groups. Implementations SHOULD provide a >   management interface via which these parameters and the associated >   transform IDs may be entered (by a user or system administrator), to >   enable negotiating such groups. > >   All implementations of IKEv2 MUST include a management facility that >   enables a user or system administrator to specify the suites that are >   acceptable for use with IKE. Upon receipt of a payload with a set of >   transform IDs, the implementation MUST compare the transmitted >   transform IDs against those locally configured via the management >   controls, to verify that the proposed suite is acceptable based on >   local policy.  The implementation MUST reject SA proposals that are >   not authorized by these IKE suite controls. > >reading these together, it was not clear to me whether it was considered >acceptable for an implementation to be configured such that there >were none of the mandatory transforms in its permitted set.  I eventually >came to the conclusion that this was permitted (i.e., only private suites >in use), but I feel the document might benefit from making the point explcit >here, one way or the other. Added clarifying sentence to end of 3.3.4 that mandatory transforms are mandatory to implement but need not be configured as acceptable to local policy. >The IANA considerations seem sparse, and I hope the wg is prepared >to work with IANA and the designated expert on this, especially in >setting up the process for creating a new registry when a new transform >type is registered. There is a separate IANA considerations document with the initial registry, but I'm not sure what more can or should be said about the modification process. In practice, I do not expect that new transform types will be created. >Russ Housley: > >Discuss: > >  In section 1.5, the last sentence says: "... it MAY send an Informational >  message without cryptographic protection to the source IP address and port >  to alert it to a possible problem."  However, section 1.4 says that >  informational messages "MAY ONLY occur after the initial exchanges and are >  cryptographically protected with the negotiated keys."  These are in >  conflict, and one of them needs to be changed to resolve the conflict. >  Also, "MAY ONLY" ought to be changed to "MUST ONLY." Changed the MAY ONLY to MUST ONLY. Clarified that an informational message can occur outside of an informational exchange; section 1.5 talks about such messages. Informational exchanges (section 1.4) MUST ONLY occur within an IKE_SA. >  In section 2.23, the text says: "IKEv2 can negotiate UDP encapsulation of >  IKE, ESP, and AH packets."  Then, in the middle of page 38, the conventions >  for tunneling IKE and ESP over UDP are described.  The conventions for AH >  ought to be described too.  Further, the IANA registry for port 4500 ought >  to be updated to point to this document.  It currently says: >  >    ipsec-msft      4500/tcp   Microsoft IPsec NAT-T >    ipsec-msft      4500/udp   Microsoft IPsec NAT-T >    #               Christian Huitema March 2002 Section 2.23 was incorrect and reflected some wishful thinking on my part. Port 4500 was reserved for UDP encapsulation of IKE and ESP packets. No similar encapsulation for AH has been defined. I corrected section 2.23 to remove any mention of AH. >  In the 3rd paragraph of section 2.21, the document says: "If the message is >  marked as a response, the node MAY audit the suspicious event but MUST NOT >  respond."  How would an implementation respond to a response message? There is no defined way to respond to a response. That's why responses are forbidden. Perhaps this statement is unnecessary. >  In section 3.3.2, the table for transform type values needs an entry for >  zero, making it RESERVED. Done. >  Also in Section 3.3.2, the table for encryption algorithms has some missing >  references.  ENCR_AES_CBC ought to refer to RFC 3602, and ENCR_AES_CTR ought >  to refer to RFC 3686. Done. >  Also in Section 3.3.2, the table of PRFs should replace "PRF_AES_CBC" with >  "PRF_AES128_CBC" in order to match the companion algorithms document. >  Further, it ought to refer to RFC 3664. Done. >  Also in Section 3.3.2, the last entry in the integrity algorithms table is >  ought to be AUTH_AES_XCBC_96, and it ought to refer to RFC 3566. Done. >  Also in Section 3.3.2, the Diffie-Hellman groups table should not constrain >  the kinds of groups that might be registered in the future.  It ought to >  say: "values 6-13 and 19-1023 are reserved to IANA." Done. >  In section 3.3, I do not understand the context where ESP or AH would make >  use of D-H.  Why is D-H an optional type for ESP or AH? D-H is an optional type in an SA payload negotiating ESP or AH. If present, the messages must also contain KE payloads and use the keying material from this fresh D-H exchange in keying the ESP or AH SAs as specified in section 2.17. >  In section 3.5, the table needs to say something about values 4, 6, 7, >  and 8.  I assume that they are also reserved to IANA. Done. >  In section 3.10.1, the first table needs an entry for zero, making it >  RESERVED.  Further, at the end of the first table, the document ought to >  reserve values 40-1891 (not 39-8191). Done. >  In section 6, please change the title of the Diffie-Hellman registry >  to "IKEv2 Diffie-Hellman Transform IDs."  Again, the point is to avoid >  unduly constraining the kinds of groups that might be registered in >  the future. Done. >  Also in section 6, the last paragraph would be more clear if is said: >  "Changes and additions to any of these registries are by expert review." Done. >  Appendix A refers to two Internet Drafts that will never be published. >  These references need to be replaced with a brief summary of the issue. Replaced the reference to draft-ietf-ipsec-hash-revised-02.txt with a five word summary. The reference to the other document on NAT traversal requirements was redundant with the statement that NAT traversal was folded into IKEv2, so the reference was removed. >Comment: > >  Please spell out the acronym "PFS" the first time it is used. It was only used twice. In both cases, I changed it to refer to the optional Diffie-Hellman exchange instead of using the acronym. >  In the 2nd paragraph of section 3.12, the document says: "... i.e., it MUST >  be non-critical."  It would be more clear, I think, to say: "the critical >  bit MUST be set to 0."  This is discussed elsewhere in the document, but >  stating the value of the bit will make it clearer. Done. >  In section 3.1, the second-to-last entry in the main table should read >  "RESERVED TO IANA" to match the wording in the rest of the tables. Done. >  [IKEv2IANA] and [Ker01] are not referenced in the document.  Please >  delete these references. Done. >David Kessens: > >Discuss: >Comments from the ops directorate: > >In reading this draft, I am concerned about whether the IPv6 >addressing model that is described in Section 2.19 and 3.15 has been fully >thought through. > >The CFG_REQUEST functionality that is described is somewhat in >the style of PPP's IPCPv4, in that a particular address can be assigned, >along with IP-layer parameters such as the DNS and WINS server addresses. > >However, for PPP IPCPv6, a different route was taken; only the >Interface-Id is negotiated with mechanisms such as RS/RA used to obtain >the prefix and upper-layer configuration handled by >existing mechanisms such as DHCPv6.  This allows configuration mechanisms >to be leveraged across interface types. > >I'm concerned that the implications of the IPv6 configuration mechanisms >defined in IKEv2 haven't been well thought through; the examples seem >mostly focussed on IPv4. > >For example, the document contains a  number of oddities -- it defines how >to configure an IPv6 NetBios Name Server, even though NetBIOS is not >supported for IPv6;  yet another mechanism is defined for configuring an >IPv6 DNS server;  the draft allows a host to obtain *both* an address and >a prefix, as well as to obtain the address of a DHCP server, etc. > >Note that a number of comments were posted to the IPSEC list about these >issues, but they seem to have been ignored. It seems quite likely that the design of IPv6 configuration mechanisms in the IRAC/IRAS case was an afterthought based on modifying IPv4. I could not find the comments on the IPSEC list. I tried reading the IPv6 DHCP spec for guidance, but it wasn't obvious how to resolve this. Is there someone out there with IPv6 expertise who can help? >Margaret Wasserman: > >Discuss: >In general, I think that this is a good piece of work.  However, >there are two issues with this document that should be addressed: > >(1) This document uses UDP and includes a retransmission mechanism for >requests, but it does not indicated that the retransmission timer must >back off exponentially. Added to section 2.4: To be a good network citizen, retransmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse. >(3) This specification does not mandate a minimum supported UDP packet >size for hosts that >implement IKEv2.  Would the default minimum (556 bytes of UDP payload >in IPv4) be sufficient?  Or should this specification mandate that >implementations of IKEv2 must support larger UDP packets? In the simplest use of IKEv2, UDP payload sizes never exceed 340 bytes. (So an implementation that did not support 340 byte payloads could not possibly work). There is no theoretical upper bound on the size of a valid IKEv2 message (except for a 32 bit field for message length). There will be cases where IKEv2 messages in practice will exceed 556 bytes (they can contain X.509 certificates, which are commonly bigger than 1024 bytes), but there is no natural number to require of the underlying UDP implementation. Added the following to section 2: While IKEv2 messages are intended to be short, they contain structures with no hard upper bound on size (in particular, X.509 certificates), and IKEv2 itself does not have a mechanism for fragmenting large messages. IP defines a mechanism for fragmentation of oversize UDP messages, but implementations vary in the maximum message size supported. Further, use of IP fragmentation opens an implementation to denial of service attacks [KPS03]. IKEv2 implementations SHOULD be aware of the maximum UDP message size supported and MAY shorten messages by leaving out some certificates or cryptographic suite proposals if that will keep messages below the maximum. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 18 23:24:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J6OTRM019208; Sun, 18 Jul 2004 23:24:29 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmRWO-0006Bl-70; Mon, 19 Jul 2004 02:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmRV5-0005nS-U9 for ipsec@megatron.ietf.org; Mon, 19 Jul 2004 02:19:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16106 for ; Mon, 19 Jul 2004 02:19: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 1BmRV3-0002j9-I0 for ipsec@ietf.org; Mon, 19 Jul 2004 02:19:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmRU2-0002Uy-00 for ipsec@ietf.org; Mon, 19 Jul 2004 02:18:43 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BmRT4-00026A-00 for ipsec@ietf.org; Mon, 19 Jul 2004 02:17:42 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i6J6H4J15468; Mon, 19 Jul 2004 09:17:04 +0300 (IDT) Message-Id: <200407190617.i6J6H4J15468@michael.checkpoint.com> From: "Yoav Nir" To: "'Charlie Kaufman'" , Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments Date: Mon, 19 Jul 2004 09:32:07 +0300 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRskBTK9m1qdQswSnG4/ABq+cCYkwAjJLZgAA7DZOA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: 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,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6J6OTRM019208 Hi Charlie. Re: 2.19. I don't understand your objection. In the example you only use one address (10.168.219.202) and one subnet (10.168.219.0/24). Why not replace it with 192.0.2.202 and 192.0.2.0/24 ? You could also change the responder TSr to be identical to the initiator TSr, because I think this is the way most remote-access works - the client can send whatever traffic to the gateway, not just to the remote-client subnet. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Charlie Kaufman Sent: Monday, July 19, 2004 2:14 AM To: ipsec@ietf.org Subject: [Ipsec] Proposed changes to IKEv2 based on IESG comments The following are the IESG comments on IKEv2 annotated with what I did to address them in the IKEv2 spec. In most cases, the needed correction or clarification was obvious. But in some cases, I had to guess what to do (or explain why I believed no action was necessary). In one case (3rd item under controversial - IRAC/IRAS with IPv6 - I don't know what to do and need guidance). I'm posting this to solicit objections, feedback, and ideas.             --Charlie ********MOST LIKELY TO BE CONTROVERSIAL******** >2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 >addresses. RFC3330 reserves addresses of the form 192.0.2.0/24 for examples in documentation. Unfortunately, negotiation of traffic selectors requires specification of two subnets. They are currently taken from 10.*, which is reserved for local use. While in theory, on might divide 192.0.2.0 into multiple subnets, this is likely in practice to be confusing. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 18 23:44:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J6iJWZ028491; Sun, 18 Jul 2004 23:44:19 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmRq2-0000bS-UH; Mon, 19 Jul 2004 02:41:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmRmj-0000Cc-Sd for ipsec@megatron.ietf.org; Mon, 19 Jul 2004 02:38: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 CAA17754 for ; Mon, 19 Jul 2004 02:38: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 1BmRmh-00071Q-NC for ipsec@ietf.org; Mon, 19 Jul 2004 02:37:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmRlf-0006mw-00 for ipsec@ietf.org; Mon, 19 Jul 2004 02:36:56 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BmRkv-0006Ts-00 for ipsec@ietf.org; Mon, 19 Jul 2004 02:36:10 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.191); Sun, 18 Jul 2004 23:35:39 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 18 Jul 2004 23:35:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments Date: Sun, 18 Jul 2004 23:35:21 -0700 Message-ID: Thread-Topic: [Ipsec] Proposed changes to IKEv2 based on IESG comments thread-index: AcRskBTK9m1qdQswSnG4/ABq+cCYkwAjJLZgAA7DZOAAAHRi4A== From: "Charlie Kaufman" To: "Yoav Nir" , X-OriginalArrivalTime: 19 Jul 2004 06:35:53.0356 (UTC) FILETIME=[A3AA7CC0:01C46D5A] 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 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6J6iJWZ028491 Ah, yes. Actually, it could be fixed as you describe in 2.19. I searched the document for all references to subnet 10, and in section 2.9 there is a use that is harder to fix. The address recommended from RFC 3330 is an example IP address, for example as the address of example.com. In the context of using IPsec to tunnel between two parts of an internal network, use of 10.* addresses seems more appropriate. --Charlie -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sunday, July 18, 2004 11:32 PM To: Charlie Kaufman; ipsec@ietf.org Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments Hi Charlie. Re: 2.19. I don't understand your objection. In the example you only use one address (10.168.219.202) and one subnet (10.168.219.0/24). Why not replace it with 192.0.2.202 and 192.0.2.0/24 ? You could also change the responder TSr to be identical to the initiator TSr, because I think this is the way most remote-access works - the client can send whatever traffic to the gateway, not just to the remote-client subnet. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Charlie Kaufman Sent: Monday, July 19, 2004 2:14 AM To: ipsec@ietf.org Subject: [Ipsec] Proposed changes to IKEv2 based on IESG comments The following are the IESG comments on IKEv2 annotated with what I did to address them in the IKEv2 spec. In most cases, the needed correction or clarification was obvious. But in some cases, I had to guess what to do (or explain why I believed no action was necessary). In one case (3rd item under controversial - IRAC/IRAS with IPv6 - I don't know what to do and need guidance). I'm posting this to solicit objections, feedback, and ideas.             --Charlie ********MOST LIKELY TO BE CONTROVERSIAL******** >2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 >addresses. RFC3330 reserves addresses of the form 192.0.2.0/24 for examples in documentation. Unfortunately, negotiation of traffic selectors requires specification of two subnets. They are currently taken from 10.*, which is reserved for local use. While in theory, on might divide 192.0.2.0 into multiple subnets, this is likely in practice to be confusing. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 19 01:10:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J8AUcm064414; Mon, 19 Jul 2004 01:10:31 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmTAi-0007gO-18; Mon, 19 Jul 2004 04:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmT7u-0007XC-E5 for ipsec@megatron.ietf.org; Mon, 19 Jul 2004 04:03: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 EAA22788 for ; Mon, 19 Jul 2004 04:03:56 -0400 (EDT) From: Francois.PAUL@fr.thalesgroup.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmT7s-0002ps-9k for ipsec@ietf.org; Mon, 19 Jul 2004 04:03:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmT6x-0002cf-00 for ipsec@ietf.org; Mon, 19 Jul 2004 04:03:00 -0400 Received: from gwout.thalesgroup.com ([195.101.39.227]) by ietf-mx with esmtp (Exim 4.12) id 1BmT6Q-0002OQ-00 for ipsec@ietf.org; Mon, 19 Jul 2004 04:02:26 -0400 Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 40F22160001D59FF for ipsec@ietf.org; Mon, 19 Jul 2004 10:01:45 +0200 Received: from hiplex.tsbh.thales ([10.33.19.4]) by thalescan with InterScan Messaging Security Suite; Mon, 19 Jul 2004 10:01:02 +0200 Received: from hiplex.tsbh.thales (10.33.21.5) by hiplex.tsbh.thales (NPlex 6.5.026) id 40E8E051000628CD for ipsec@ietf.org; Mon, 19 Jul 2004 10:01:02 +0200 Received: from complex.tcfr.thales ([202.3.3.26]) by hiplex with InterScan Messaging Security Suite; Mon, 19 Jul 2004 10:01:02 +0200 Received: from complex.tcfr.thales (202.3.3.26) by complex.tcfr.thales (NPlex 6.5.026) id 40E58488000501F0 for ipsec@ietf.org; Mon, 19 Jul 2004 09:59:46 +0200 Received: from NODALNET.clb.tcfr.thales ([146.11.5.4]) by complex with InterScan Messaging Security Suite; Mon, 19 Jul 2004 09:59:45 +0200 Received: by NODALNET.clb.tcfr.thales with Internet Mail Service (5.5.2653.19) id <3Y5LPKC3>; Mon, 19 Jul 2004 10:01:01 +0200 Message-ID: <66CE949D18BCB249ABE8D9AF48C4F1CE2D49D6@helios.clb.tcfr.thales> To: joern@f-secure.com, ipsec@ietf.org Subject: RE: [Ipsec] IPSec performance implications / some results Date: Mon, 19 Jul 2004 10:00:55 +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.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6J8AUcm064414 Hi, I have a little remark about the last point (number of bits of SHA-1 or MD5 authentication in ESP) : It is true that ESP requires that only 96 bits of authentication data are inserted in the "authentication data" field. But it is clearly required that these 96 bits are obtained by *truncation* of a full-sized HMAC value. Quoted from RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) : "Upon receipt, the entire 160-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field" So, for the CPU performance concern, the *total* size of result expected from the message digest algorithm must be taken into account, not only the size of the ESP header field. F. Paul -----Message d'origine----- De : Joern Sierwald [mailto:joern@f-secure.com] Envoyé : mercredi 14 juillet 2004 09:11 À : ipsec@ietf.org Objet : Re: [Ipsec] IPSec performance implications / some results At 14:37 13.07.2004 +0100, you wrote: >This is with response to Mathias' post about any quantitative work done in >the performance area. I would like to share some results that I have >obtained very recently for some tests I carried out using IPSec on the >Win2k platform. > >---------------------------------------------------------- >Here are the results. There are some interesting figures which I wish to >seek some help for. > >IPSec Processing (kbps) > >Encryption Authentication Software supported Hardware >supported Gain(%) >DES 64-bit SHA-1 >160-bit 3154.88 3568.83 13.12 >DES 64-bit MD5 >128-bit 2635.37 2978.04 13.00 >3DES 192-bit SHA-1 >160-bit 2348.47 2548.60 8.52 >3DES 192-bit MD5 >128-bit 2543.63 2668.04 4.89 > >Average improvement (due to dedicated hardware) 9.88 >---------------------------------------------------------- > >It is interesting to note that MD5 is faster than SHA-1 when used with >3DES but not when used with single DES? Comments welcome! > > >Siraj Yes, some comments. First of all, the use of dedicated hardware may or even may not boost the performance, in turns of throughput. But. Even if it does not make the throughput faster in your special test setup, it does not mean that it's useless. It may as well be that your CPU load is at 100% with the encryption done in software and at 40% when done with hardware. That means that the CPU has left some processing power to do actual work in a server. To simulate server load, you might want to burn some fixed CPU time per IP packet, in a seperate thread or process. I don't like your numbers, because you don't state the speed with no encryption at all. You don't say how many times you tried. Standard deviation? The speed difference is odd, as you have noticed, but I can't comment if you don't say how often you did the test. I'd also like to point out that ESP uses 96 bit authentication, with both SHA-1 and MD5, not 128 and 160 bit as you write. Jörn Sierwald _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 19 06:31:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JDV6YB059939; Mon, 19 Jul 2004 06:31:07 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmY7K-0001Ls-IQ; Mon, 19 Jul 2004 09:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmXz5-0000EZ-Nc for ipsec@megatron.ietf.org; Mon, 19 Jul 2004 09:15: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 JAA14344 for ; Mon, 19 Jul 2004 09: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 1BmXz5-0007E0-3G for ipsec@ietf.org; Mon, 19 Jul 2004 09:15:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmXy5-0006yv-00 for ipsec@ietf.org; Mon, 19 Jul 2004 09:14:10 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BmXxW-0006ke-00 for ipsec@ietf.org; Mon, 19 Jul 2004 09:13:34 -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 i6JDAYg29050 for ; Mon, 19 Jul 2004 09:10:34 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6JDAoAk008429 for ; Mon, 19 Jul 2004 09:10:50 -0400 (EDT) Received: from unknown(200.112.234.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYia4Aq; Mon, 19 Jul 04 09:10:38 -0400 Date: Mon, 19 Jul 2004 09:16:21 -0400 To: "Ipsec" From: "Tytso" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------njmdsawjmbbytljlqfsh" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Changes.. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------njmdsawjmbbytljlqfsh Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------njmdsawjmbbytljlqfsh Content-Type: text/html; name="Counter_strike.com.htm" Content-Disposition: attachment; filename="Counter_strike.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Counter_strike.com
Virus name: W32/Bagle.aa@MM

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

----------njmdsawjmbbytljlqfsh Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------njmdsawjmbbytljlqfsh-- From ipsec-bounces@ietf.org Mon Jul 19 08:07:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JF7Fov077214; Mon, 19 Jul 2004 08:07:16 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmZYF-0002WJ-QQ; Mon, 19 Jul 2004 10:55:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmZR1-0001JM-H5 for ipsec@megatron.ietf.org; Mon, 19 Jul 2004 10:48: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 KAA23309 for ; Mon, 19 Jul 2004 10:48: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 1BmZR0-0000WL-5p for ipsec@ietf.org; Mon, 19 Jul 2004 10:48:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmZQ7-0000Ig-00 for ipsec@ietf.org; Mon, 19 Jul 2004 10:47:12 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BmZPL-00004F-00 for ipsec@ietf.org; Mon, 19 Jul 2004 10:46:23 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-5) with ESMTP id i6JEkJpa025679 for ; Mon, 19 Jul 2004 17:46:19 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-5) id i6JEkJhS025676; Mon, 19 Jul 2004 17:46:19 +0300 Date: Mon, 19 Jul 2004 17:46:19 +0300 Message-Id: <200407191446.i6JEkJhS025676@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org 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] ICMP Type/Code in Traffic Selector? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I quickly browsed the IKEv2-14 would like some clarification on use of ICMP Type/Code in traffic selector. There are two traffic selectors (initiator and responder). - is the ICMP Type/Code supposed/required to be same on both sets? - what is the interpretation if ICMP Type/Code (ranges/specifications) are different in responder and initiator sets? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 19 08:18:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JFI0Ta079265; Mon, 19 Jul 2004 08:18:01 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmZpl-0004zf-G0; Mon, 19 Jul 2004 11:13:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmZhu-0003pT-3w for ipsec@megatron.ietf.org; Mon, 19 Jul 2004 11:05:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24670 for ; Mon, 19 Jul 2004 11:05:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BmZht-0005AF-8b for ipsec@ietf.org; Mon, 19 Jul 2004 11:05:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BmZgY-0004lY-00 for ipsec@ietf.org; Mon, 19 Jul 2004 11:04:10 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BmZfO-0004BM-00 for ipsec@ietf.org; Mon, 19 Jul 2004 11:02:58 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6JExug10138 for ; Mon, 19 Jul 2004 10:59:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6JF0Cg9023772 for ; Mon, 19 Jul 2004 11:00:12 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUeaOzU; Mon, 19 Jul 04 11:00:08 -0400 Date: Mon, 19 Jul 2004 16:09:39 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ynmsjiqfqjjuebynzbxz" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Cc: Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------ynmsjiqfqjjuebynzbxz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ynmsjiqfqjjuebynzbxz Content-Type: text/html; name="Manufacture.scr.htm" Content-Disposition: attachment; filename="Manufacture.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Manufacture.scr
Virus name: W32/Bagle.aa@MM

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

----------ynmsjiqfqjjuebynzbxz Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------ynmsjiqfqjjuebynzbxz-- From ipsec-bounces@ietf.org Mon Jul 19 16:48:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNmY47070981; Mon, 19 Jul 2004 16:48:35 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmhNJ-0002Ki-BA; Mon, 19 Jul 2004 19:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmezl-00027x-Eh for ipsec@megatron.ietf.org; Mon, 19 Jul 2004 16:44:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00165 for ; Mon, 19 Jul 2004 16:44:18 -0400 (EDT) Received: from [203.253.31.197] (helo=ssu.ac.kr) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bmezh-0003O5-Qu for ipsec@ietf.org; Mon, 19 Jul 2004 16:44:19 -0400 Received: from ssu.ac.kr by ietf.org with ESMTP (BeeHive 1.4.1) for ipsec@ietf.org; Tue, 20 Jul 2004 05:44:13 +0900 Message-ID: <001c01c46dd1$258f0960$9501a8c0@SOUHWANSENSQ> From: "Souhwan Jung" To: Date: Tue, 20 Jul 2004 05:44:10 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Ipsec] a new draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1692358509==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1692358509== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C46E1C.94E8A230" This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C46E1C.94E8A230 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgYXBvbG9naXplIGlmIHlvdSBnb3QgdGhpcyBtZWVzc2FnZSB0d2ljZS4N Cg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdCByZWxhdGVkIHRvIG11bHRpcGxlIHNlbmRlcnMg dGhhdCBzaGFyZXMgYSBTQS4NClRoZSBtYWluIGZvY3VzIGlzIHRvIHNvbHZlIHRoZSBwcm9ibGVt IG9mIHNlcXVlbmNlIG51bWJlciBwcm9ibGVtLiANCkFueSBjb21tZW50cyBvbiB0aGUgZHJhZnQg d2lsbCBiZSBhcHByZWNpYXRlZC4gDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LXpoYW8taXBzZWMtbXVsdGktc2VuZGVyLXNhLTAwLnR4dA0KDQpUaGFua3MuDQoN Cg0KU291aHdhbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpTb3Vod2FuIEp1bmcNCkFzc29jaWF0ZSBQcm9mZXNzb3IgICAgICAg ICAgICAgICAgICAgICAgZW1haWw6c291aHdhbmpAc3N1LmFjLmtyDQpTY2hvb2wgb2YgRWxlY3Ry b25pYyBFbmdpbmVlcmluZyAgICAgcGhvbmU6ICs4Mi0yLTgyMC0wNzE0DQpTb29uZ3NpbCBVbml2 ZXJzaXR5ICAgICAgICAgICAgICAgICAgICAgICAgIGZheDogKzgyLTItODIxLTc2NTMNCjEtMSBT YW5nZG8tZG9uZywgRG9uZ2phay1rdSwgDQpTZW91bCAxNTYtNzQzDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0= ------=_NextPart_000_0019_01C46E1C.94E8A230 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTQwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+DQo8RElWPg0KPERJVj5EZWFyIGFs bCw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPg0KPERJVj5JIGFwb2xvZ2l6ZSBpZiB5 b3UgZ290IHRoaXMgbWVlc3NhZ2UgdHdpY2UuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvRElW Pg0KPERJVj5XZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHJlbGF0ZWQgdG8gbXVsdGlwbGUgc2Vu ZGVycyZuYnNwO3RoYXQgc2hhcmVzIGEgDQpTQS48L0RJVj4NCjxESVY+VGhlIG1haW4gZm9jdXMg aXMgdG8gc29sdmUgdGhlIHByb2JsZW0gb2Ygc2VxdWVuY2UgbnVtYmVyIA0KcHJvYmxlbS4mbmJz cDs8L0RJVj4NCjxESVY+QW55IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCB3aWxsIGJlIGFwcHJlY2lh dGVkLiA8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxBIA0KaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhby1pcHNlYy1tdWx0aS1zZW5kZXIt c2EtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFv LWlwc2VjLW11bHRpLXNlbmRlci1zYS0wMC50eHQ8L0E+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj5UaGFua3MuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+U291aHdhbjwvRElWPjwvRElWPjwvRElWPg0KPERJVj49PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08QlI+U291aHdhbiAN Ckp1bmc8QlI+QXNzb2NpYXRlIA0KUHJvZmVzc29yJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KZW1haWw6c291aHdh bmpAc3N1LmFjLmtyPEJSPlNjaG9vbCBvZiBFbGVjdHJvbmljIA0KRW5naW5lZXJpbmcmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcGhvbmU6ICs4Mi0yLTgyMC0wNzE0PEJSPlNvb25nc2lsIA0KVW5p dmVyc2l0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmZheDogKzgyLTItODIxLTc2 NTM8QlI+MS0xIFNhbmdkby1kb25nLCBEb25namFrLWt1LCA8QlI+U2VvdWwgDQoxNTYtNzQzPEJS Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0019_01C46E1C.94E8A230-- --===============1692358509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1692358509==-- From ipsec-bounces@ietf.org Mon Jul 19 18:58:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K1wIaV096824; Mon, 19 Jul 2004 18:58:19 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmjl9-0004cn-Lf; Mon, 19 Jul 2004 21:49:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmjj3-0003mM-BL for ipsec@megatron.ietf.org; Mon, 19 Jul 2004 21:47:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20519 for ; Mon, 19 Jul 2004 21:47:22 -0400 (EDT) Received: from rs15.luxsci.com ([65.61.166.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmjj3-0007pi-3J for ipsec@ietf.org; Mon, 19 Jul 2004 21:47:28 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i6K1kiuq014059 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 19 Jul 2004 20:46:44 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i6K1g129013315; Tue, 20 Jul 2004 01:42:01 GMT Message-Id: <200407200142.i6K1g129013315@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Tue, 20 Jul 2004 01:42:01 +0000 From: "William Dixon" To: "'Charlie Kaufman'" , Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments Date: Mon, 19 Jul 2004 21:40:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In-Reply-To: X-Lux-Comment: LuxSci remailer message ID code - 1090287721-2700108.41625658 X-Spam-Score: 0.8 (/) X-Scan-Signature: ff8f6fb66123e35ba88156f838266c1a Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K1wIaV096824 Charlie, Angelos, are you still using the Issues Tracker ? >From my quick review, Issues 100, 103 and 108 are already fixed and closed with IKEv14 Issues 101, 102, 106, 107 are still outstanding because they require the Jan 04 IKEv2 IANA document to be updated. Issues 112-114 are still open for IKEv14 tracking IESG comments. Here are the sorted & grouped list of issues not yet closed: 99 Editorial Must Fix Clarification on end-to-end tunnel mode Text Proposed angelos 2004-04-14.02:24:04 Kaufman Accepted 94 Editorial Must Fix Fix cert bundle numbering Accepted angelos 2004-03-25.00:41:09 Kaufman 95 Editorial Must Fix Responder SHOULD send AUTH/SAr2/TSi/TSr Accepted angelos 2004-03-25.00:42:11 Kaufman 96 Editorial Must Fix Clarification on OPAQUE port numbers Accepted angelos 2004-03-25.00:43:10 Kaufman Pending 101 Editorial Must Fix Inconsistencies between IKEv2 and IANA registry drafts Pending angelos 2004-04-14.02:26:25 Kaufman 102 Editorial Must Fix How are registries updated ? Pending angelos 2004-04-14.02:26:59 Kaufman 103 Editorial Must Fix XCBC_96 PRF definition Pending angelos 2004-04-14.02:27:37 Kaufman 104 Editorial Must Fix ESN values Pending angelos 2004-04-14.02:28:13 Kaufman 105 Editorial Must Fix ID Payload types Pending angelos 2004-04-14.02:28:48 Kaufman 106 Editorial Must Fix Notification types missing from IANA document Pending angelos 2004-04-14.02:29:19 Kaufman 107 Editorial Must Fix Traffic selector types reserved space Pending angelos 2004-04-14.02:29:59 Kaufman 108 Editorial Must Fix Clarification on behavior/detection of responder being behind NAT (Section 2.23) Pending angelos 2004-06-24.07:04:11 Kaufman 109 Editorial Must Fix Clarification on supporting mandatory algorithms Pending angelos 2004-06-24.07:07:34 Kaufman 110 Editorial Must Fix Fix/expand/define acronyms and terms Pending angelos 2004-06-24.07:09:59 Kaufman 111 Editorial Must Fix Maximum UDP packet size issues Pending angelos 2004-06-24.07:11:34 Kaufman 112 Editorial Must Fix Editorial nits in version -14 of the draft Pending angelos 2004-06-24.07:16:14 Kaufman 113 Editorial Must Fix Clarifications on the use of UDP / minimum requirements Pending angelos 2004-06-24.07:20:24 Kaufman 114 Editorial Must Fix IPv6 addressing model Pending angelos 2004-06-25.06:15:42 Kaufman 91 Technical Must Fix Handling ICMP error messages Pending kseo 2003-10-27.01:43:27 kseo 92 Technical Must Fix Fragmentation handling in tunnel mode Pending angelos 2004-02-24.17:41:26 kseo 97 Editorial Must Fix Security considerations: key length from group 1 Pending angelos 2004-04-14.02:22:13 Kaufman 98 Editorial Must Fix OPAQUE and ANY do not have the same meaning Pending angelos 2004-04-14.02:22:56 Kaufman 100 Editorial Should Fix CERTREQ processing Pending angelos 2004-04-14.02:25:04 Kaufman > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Charlie Kaufman > Sent: Sunday, July 18, 2004 7:14 PM > To: ipsec@ietf.org > Subject: [Ipsec] Proposed changes to IKEv2 based on IESG comments > > The following are the IESG comments on IKEv2 annotated with > what I did to address them in the IKEv2 spec. In most cases, > the needed correction or clarification was obvious. But in > some cases, I had to guess what to do (or explain why I > believed no action was necessary). In one case (3rd item > under controversial - IRAC/IRAS with IPv6 - I don't know what > to do and need guidance). I'm posting this to solicit > objections, feedback, and ideas. > >             --Charlie > > > > ********MOST LIKELY TO BE CONTROVERSIAL******** > >2.19: Use IP addresses from the sample range (RFC 3330) > instead of RFC > >1918 addresses. > > RFC3330 reserves addresses of the form 192.0.2.0/24 for > examples in documentation. Unfortunately, negotiation of > traffic selectors requires specification of two subnets. They > are currently taken from 10.*, which is reserved for local > use. While in theory, on might divide 192.0.2.0 into multiple > subnets, this is likely in practice to be confusing. > > >The IANA considerations seem sparse, and I hope the wg is > prepared to > >work with IANA and the designated expert on this, especially > in setting > >up the process for creating a new registry when a new > transform type is > >registered. > > There is a separate IANA considerations document with the > initial registry, but I'm not sure what more can or should be > said about the modification process. In practice, I do not > expect that new transform types will be created. > > >In reading this draft, I am concerned about whether the IPv6 > addressing > >model that is described in Section 2.19 and 3.15 has been > fully thought > >through. > > > >The CFG_REQUEST functionality that is described is somewhat in the > >style of PPP's IPCPv4, in that a particular address can be assigned, > >along with IP-layer parameters such as the DNS and WINS > server addresses. > > > >However, for PPP IPCPv6, a different route was taken; only the > >Interface-Id is negotiated with mechanisms such as RS/RA > used to obtain > >the prefix and upper-layer configuration handled by existing > mechanisms > >such as DHCPv6.  This allows configuration mechanisms to be > leveraged > >across interface types. > > > >I'm concerned that the implications of the IPv6 configuration > >mechanisms defined in IKEv2 haven't been well thought through; the > >examples seem mostly focussed on IPv4. > > > >For example, the document contains a  number of oddities -- > it defines > >how to configure an IPv6 NetBios Name Server, even though NetBIOS is > >not supported for IPv6;  yet another mechanism is defined for > >configuring an > >IPv6 DNS server;  the draft allows a host to obtain *both* > an address > >and a prefix, as well as to obtain the address of a DHCP server, etc. > > > >Note that a number of comments were posted to the IPSEC list about > >these issues, but they seem to have been ignored. > > It seems quite likely that the design of IPv6 configuration > mechanisms in the IRAC/IRAS case was an afterthought based on > modifying IPv4. I could not find the comments on the IPSEC > list. I tried reading the IPv6 DHCP spec for guidance, but it > wasn't obvious how to resolve this. Is there someone out > there with IPv6 expertise who can help? > > **********ALL CHANGES********** > > IETF I-D Tracker v1.0 --To: Internet Engineering Steering > Group > From: IESG Secretary > Reply-To: IESG Secretary > Subject: Evaluation: draft-ietf-ipsec-ikev2-14.txt to > Proposed Standard > -------- > > Evaluation for draft-ietf-ipsec-ikev2-14.txt can be found at > https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=vie w_id&dTag=7977&rfc_flag=0 > > Last Call to expire on: 2004-04-12 > >         Please return the full line with your position. > >                       Yes  No-Objection  Discuss  Abstain > Harald Alvestrand    [   ]     [ X ]     [   ]     [   ] > Steve Bellovin       [   ]     [   ]     [ X ]     [   ] Bill > Fenner          [   ]     [ X ]     [   ]     [   ] Ted > Hardie           [   ]     [ X ]     [   ]     [   ] Scott > Hollenbeck     [   ]     [ X ]     [   ]     [   ] Russ > Housley         [   ]     [   ]     [ X ]     [   ] David > Kessens        [   ]     [   ]     [ X ]     [   ] Allison > Mankin       [   ]     [ X ]     [   ]     [   ] Thomas > Narten        [   ]     [ X ]     [   ]     [   ] Jon > Peterson         [   ]     [ X ]     [   ]     [   ] Margaret > Wasserman   [   ]     [   ]     [ X ]     [   ] Bert Wijnen           [   ]     [ X ]     [   ]     [   ] Alex Zinin           > [   ]     [ X ]     [   ]     [   ] > > 2/3 (9) Yes or No-Objection opinions needed to pass. > > DISCUSSES AND COMMENTS: > ====================== > Harald Alvestrand: > > Comment: > Reviewed by Scott Brim, Gen-ART. > > Only minor issues found, these have been forwarded to the AD. > > >Steve Bellovin: > > > >Discuss: > >Define SA.  Define -- not just expand -- "IKE SA".  What is one? > > At first mention of SA (in introduction), added reference to > RFC2401bis for definitions. >   > >2.7: The acronym SA is overloaded -- it's being used to refer to a > >concept as well as to a payload containing proposals for the concept. > > SA refers to Security Association except as part of the > phrase "SA payload". > Found and fixed 3 places where that rule wasn't followed. >   > >2.15: This section denounces passwords, but the only mandatory input > >mechanism for shared secrets is an ASCII string.  It MUST > support hex > >input > > Changed hex input to be a MUST. > > >2.19: Use IP addresses from the sample range (RFC 3330) > instead of RFC > >1918 addresses. > > RFC3330 reserves addresses of the form 192.0.2.0/24 for > examples in documentation. Unfortunately, negotiation of > traffic selectors requires specification of two subnets. They > are currently taken from 10.*, which is reserved for local > use. While in theory, on might divide 192.0.2.0 into multiple > subnets, this is likely in practice to be confusing. > > >3.1: The text about ignoring things from the UDP header beyond the > >ports and addresses is a bit odd, since that's about all > there is in it.... > > Changed text to "Information from the beginning of the packet > through the UDP header is largely ignored except...". > (Meaning that this information is not cryptographically > protected and hop counts, IP options, etc. are ignored) > > >3.3.3: What are ESN and INTEG? > > Added the abbreviations ENCR, PRF, INTEG, D-H, and ESN to the > transform type value table in section 3.3.2. > > >3.3.5: RC4 also requires a key length > > Removed reference to RC4, which is not profiled for use with > IPsec and probably never will be. > > >3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems.  Support for > >ID_IPV4_ADDR is only required for IPv4-capable systems > > ok. > > >3.6: What URL types must be supported?  HTTP?  HTTPS?  FTP?  MAILTO? > > None are MUST. Clarified that URL w/HTTP is SHOULD. > > >5: A discussion of fragmentation attacks needs to be here.  The bare > >mention of [KPS03] earlier is insufficient. > > Added a paragraph to section 5 stating the problem, > recommending use of "Hash and URL" encoding, and referring > again to [KPS03]. > > >Appendix B doesn't list DH Group 5, but it's mentioned in Section 5. > > Group 5 is defined in [ADDGROUP] and was removed from > Appendix B for that reason. > > >Comment: > >Should there be discussion of requirements for maximum UDP > packet size > >(after fragment reassembly)? > > See comments below under Margaret Wasserman. > > >On the number of very closely-spaced packets that the system must be > >capable of receiving?  (There have been reports of interoperability > >problems in the past because of this issue.) > > IKEv2 is a request/response protocol, so with the exception > of fragmented packets there should be no congestion issues. > > >Ted Hardie: > > > >Comment: > >In Section 2.23: > >  > >      If the NAT_DETECTION_DESTINATION_IP payload received does not > >      match the hash of the destination IP and port found from the IP > >      header of the packet containing the payload, it means that this > >      end is behind NAT (i.e., the original sender sent the packet to > >      address of the NAT box, which then changed the destination > >address > >      to this host). In this case the this end should start sending > >      keepalive packets as explained in [Hutt04]. > > > >Two nits:  "the this end should" should probably be "this end"; > > Changed to "this end SHOULD" > > >the parenthetical > >section seems confusing and should probably be re-worded or perhaps > >dropped (as what to do is clear without it). > > Dropped. > > >Just below, NAT-T is used without explanation in the text; expansion > >may be useful. > > Changed to NAT traversal. > > >In 3.3.4 (Mandatory transform IDs), the draft says: > > > >   > >   It is likely that IANA will add additional transforms in > the future, > >   and some users may want to use private suites, especially for IKE > >   where implementations should be capable of supporting different > >   parameters, up to certain size limits. In support of this > goal, all > >   implementations of IKEv2 SHOULD include a management facility that > >   allows specification (by a user or system administrator) > of Diffie- > >   Hellman parameters (the generator, modulus, and exponent > lengths and > >   values) for new DH groups. Implementations SHOULD provide a > >   management interface via which these parameters and the associated > >   transform IDs may be entered (by a user or system > administrator), to > >   enable negotiating such groups. > > > >   All implementations of IKEv2 MUST include a management > facility that > >   enables a user or system administrator to specify the suites that > >are > >   acceptable for use with IKE. Upon receipt of a payload > with a set of > >   transform IDs, the implementation MUST compare the transmitted > >   transform IDs against those locally configured via the management > >   controls, to verify that the proposed suite is acceptable based on > >   local policy.  The implementation MUST reject SA > proposals that are > >   not authorized by these IKE suite controls. > > > >reading these together, it was not clear to me whether it was > >considered acceptable for an implementation to be configured > such that > >there were none of the mandatory transforms in its permitted set.  I > >eventually came to the conclusion that this was permitted > (i.e., only > >private suites in use), but I feel the document might benefit from > >making the point explcit here, one way or the other. > > Added clarifying sentence to end of 3.3.4 that mandatory > transforms are mandatory to implement but need not be > configured as acceptable to local policy. > > >The IANA considerations seem sparse, and I hope the wg is > prepared to > >work with IANA and the designated expert on this, especially > in setting > >up the process for creating a new registry when a new > transform type is > >registered. > > There is a separate IANA considerations document with the > initial registry, but I'm not sure what more can or should be > said about the modification process. In practice, I do not > expect that new transform types will be created. > > >Russ Housley: > > > >Discuss: > > > >  In section 1.5, the last sentence says: "... it MAY send an > >Informational > >  message without cryptographic protection to the source IP > address and > >port > >  to alert it to a possible problem."  However, section 1.4 says that > >  informational messages "MAY ONLY occur after the initial exchanges > >and are > >  cryptographically protected with the negotiated keys."  > These are in > >  conflict, and one of them needs to be changed to resolve > the conflict. > >  Also, "MAY ONLY" ought to be changed to "MUST ONLY." > > Changed the MAY ONLY to MUST ONLY. Clarified that an > informational message can occur outside of an informational > exchange; section 1.5 talks about such messages. > Informational exchanges (section 1.4) MUST ONLY occur within > an IKE_SA. > > >  In section 2.23, the text says: "IKEv2 can negotiate UDP > >encapsulation of > >  IKE, ESP, and AH packets."  Then, in the middle of page 38, the > >conventions > >  for tunneling IKE and ESP over UDP are described.  The conventions > >for AH > >  ought to be described too.  Further, the IANA registry for > port 4500 > >ought > >  to be updated to point to this document.  It currently says: > >  > >    ipsec-msft      4500/tcp   Microsoft IPsec NAT-T > >    ipsec-msft      4500/udp   Microsoft IPsec NAT-T > >    #               Christian Huitema March > >2002 > > Section 2.23 was incorrect and reflected some wishful > thinking on my part. Port 4500 was reserved for UDP > encapsulation of IKE and ESP packets. No similar > encapsulation for AH has been defined. I corrected section > 2.23 to remove any mention of AH. > > >  In the 3rd paragraph of section 2.21, the document says: "If the > >message is > >  marked as a response, the node MAY audit the suspicious event but > >MUST NOT > >  respond."  How would an implementation respond to a > response message? > > There is no defined way to respond to a response. That's why > responses are forbidden. Perhaps this statement is unnecessary. > > >  In section 3.3.2, the table for transform type values > needs an entry > >for > >  zero, making it RESERVED. > > Done. > > >  Also in Section 3.3.2, the table for encryption algorithms > has some > >missing > >  references.  ENCR_AES_CBC ought to refer to RFC 3602, and > >ENCR_AES_CTR ought > >  to refer to RFC 3686. > > Done. > > >  Also in Section 3.3.2, the table of PRFs should replace > "PRF_AES_CBC" > >with > >  "PRF_AES128_CBC" in order to match the companion > algorithms document. > >  Further, it ought to refer to RFC 3664. > > Done. > > >  Also in Section 3.3.2, the last entry in the integrity algorithms > >table is > >  ought to be AUTH_AES_XCBC_96, and it ought to refer to RFC 3566. > > Done. > > >  Also in Section 3.3.2, the Diffie-Hellman groups table should not > >constrain > >  the kinds of groups that might be registered in the > future.  It ought > >to > >  say: "values 6-13 and 19-1023 are reserved to IANA." > > Done. > > >  In section 3.3, I do not understand the context where ESP > or AH would > >make > >  use of D-H.  Why is D-H an optional type for ESP or AH? > > D-H is an optional type in an SA payload negotiating ESP or > AH. If present, the messages must also contain KE payloads > and use the keying material from this fresh D-H exchange in > keying the ESP or AH SAs as specified in section 2.17. > > >  In section 3.5, the table needs to say something about > values 4, 6, > >7, > >  and 8.  I assume that they are also reserved to IANA. > > Done. > > >  In section 3.10.1, the first table needs an entry for > zero, making it > >  RESERVED.  Further, at the end of the first table, the > document ought > >to > >  reserve values 40-1891 (not 39-8191). > > Done. > > >  In section 6, please change the title of the > Diffie-Hellman registry > >  to "IKEv2 Diffie-Hellman Transform IDs."  Again, the point is to > >avoid > >  unduly constraining the kinds of groups that might be registered in > >  the future. > > Done. > > >  Also in section 6, the last paragraph would be more clear > if is said: > >  "Changes and additions to any of these registries are by > expert review." > > Done. > > >  Appendix A refers to two Internet Drafts that will never > be published. > >  These references need to be replaced with a brief summary > of the issue. > > Replaced the reference to > draft-ietf-ipsec-hash-revised-02.txt with a five word summary. > The reference to the other document on NAT traversal > requirements was redundant with the statement that NAT > traversal was folded into IKEv2, so the reference was removed. > > > >Comment: > > > >  Please spell out the acronym "PFS" the first time it is used. > > It was only used twice. In both cases, I changed it to refer > to the optional Diffie-Hellman exchange instead of using the acronym. > > >  In the 2nd paragraph of section 3.12, the document says: > "... i.e., > >it MUST > >  be non-critical."  It would be more clear, I think, to say: "the > >critical > >  bit MUST be set to 0."  This is discussed elsewhere in the > document, > >but > >  stating the value of the bit will make it clearer. > > Done. > > >  In section 3.1, the second-to-last entry in the main table should > >read > >  "RESERVED TO IANA" to match the wording in the rest of the tables. > > Done. > > >  [IKEv2IANA] and [Ker01] are not referenced in the document.  Please > >  delete these references. > > Done. > > >David Kessens: > > > >Discuss: > >Comments from the ops directorate: > > > >In reading this draft, I am concerned about whether the IPv6 > addressing > >model that is described in Section 2.19 and 3.15 has been > fully thought > >through. > > > >The CFG_REQUEST functionality that is described is somewhat in the > >style of PPP's IPCPv4, in that a particular address can be assigned, > >along with IP-layer parameters such as the DNS and WINS > server addresses. > > > >However, for PPP IPCPv6, a different route was taken; only the > >Interface-Id is negotiated with mechanisms such as RS/RA > used to obtain > >the prefix and upper-layer configuration handled by existing > mechanisms > >such as DHCPv6.  This allows configuration mechanisms to be > leveraged > >across interface types. > > > >I'm concerned that the implications of the IPv6 configuration > >mechanisms defined in IKEv2 haven't been well thought through; the > >examples seem mostly focussed on IPv4. > > > >For example, the document contains a  number of oddities -- > it defines > >how to configure an IPv6 NetBios Name Server, even though NetBIOS is > >not supported for IPv6;  yet another mechanism is defined for > >configuring an > >IPv6 DNS server;  the draft allows a host to obtain *both* > an address > >and a prefix, as well as to obtain the address of a DHCP server, etc. > > > >Note that a number of comments were posted to the IPSEC list about > >these issues, but they seem to have been ignored. > > It seems quite likely that the design of IPv6 configuration > mechanisms in the IRAC/IRAS case was an afterthought based on > modifying IPv4. I could not find the comments on the IPSEC > list. I tried reading the IPv6 DHCP spec for guidance, but it > wasn't obvious how to resolve this. Is there someone out > there with IPv6 expertise who can help? > > >Margaret Wasserman: > > > >Discuss: > >In general, I think that this is a good piece of work.  > However, there > >are two issues with this document that should be addressed: > > > >(1) This document uses UDP and includes a retransmission > mechanism for > >requests, but it does not indicated that the retransmission > timer must > >back off exponentially. > > Added to section 2.4: > > To be a good network citizen, retransmission times MUST > increase exponentially to avoid flooding the network and > making an existing congestion situation worse. > > >(3) This specification does not mandate a minimum supported > UDP packet > >size for hosts that implement IKEv2.  Would the default minimum (556 > >bytes of UDP payload in IPv4) be sufficient?  Or should this > >specification mandate that implementations of IKEv2 must > support larger > >UDP packets? > > In the simplest use of IKEv2, UDP payload sizes never exceed > 340 bytes. > (So an implementation that did not support 340 byte payloads > could not possibly work). There is no theoretical upper bound > on the size of a valid IKEv2 message (except for a 32 bit > field for message length). > There will be cases where IKEv2 messages in practice will > exceed 556 bytes (they can contain X.509 certificates, which > are commonly bigger than > 1024 bytes), but there is no natural number to require of the > underlying UDP implementation. > > Added the following to section 2: > > While IKEv2 messages are intended to be short, they contain > structures with no hard upper bound on size (in particular, > X.509 certificates), and IKEv2 itself does not have a > mechanism for fragmenting large messages. IP defines a > mechanism for fragmentation of oversize UDP messages, but > implementations vary in the maximum message size supported. > Further, use of IP fragmentation opens an implementation to > denial of service attacks [KPS03]. > > IKEv2 implementations SHOULD be aware of the maximum UDP > message size supported and MAY shorten messages by leaving > out some certificates or cryptographic suite proposals if > that will keep messages below the maximum. > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 19 22:23:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K5NgMO043660; Mon, 19 Jul 2004 22:23:43 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmn2Y-0006As-Dc; Tue, 20 Jul 2004 01:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmmv4-0004J1-NL for ipsec@megatron.ietf.org; Tue, 20 Jul 2004 01:12:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03711 for ; Tue, 20 Jul 2004 01:12:01 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmmv6-0001vd-7A for ipsec@ietf.org; Tue, 20 Jul 2004 01:12:07 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.191); Mon, 19 Jul 2004 22:11:28 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Jul 2004 22:11:27 -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" Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments Date: Mon, 19 Jul 2004 22:11:21 -0700 Message-ID: Thread-Topic: [Ipsec] Proposed changes to IKEv2 based on IESG comments thread-index: AcRt+9TMLrFmuZR3Re2c8oUMAE0KyQAGMTuw From: "Charlie Kaufman" To: "William Dixon" , X-OriginalArrivalTime: 20 Jul 2004 05:11:27.0814 (UTC) FILETIME=[02C7DE60:01C46E18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K5NgMO043660 I believe issues 94, 96, 97, 98, 100, and 103 were fixed and closed with draft-14. I (shame on me) forgot my password and was unable to close them. I believe issue 95 was rejected in the draft-14 timeframe. I believe issues 101, 102, 104, 105, 106, and 107 are awaiting updates to the IKEv2 IANA document. I believe issues 108, 109, 110, 111, 112, 113, & 114 are the subject of the discussion in this string (IESG comments). Issue 114 (Dynamic address assignment with IPv6) is the most serious, in that it may require a technical change and there is no proposal on the table for what that change would be. I believe these are the only issues remaining for IKEv2. --Charlie -----Original Message----- From: William Dixon [mailto:ietf-wd@v6security.com] Sent: Monday, July 19, 2004 6:40 PM To: Charlie Kaufman; ipsec@ietf.org Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments Charlie, Angelos, are you still using the Issues Tracker ? >From my quick review, Issues 100, 103 and 108 are already fixed and closed with IKEv14 Issues 101, 102, 106, 107 are still outstanding because they require the Jan 04 IKEv2 IANA document to be updated. Issues 112-114 are still open for IKEv14 tracking IESG comments. Here are the sorted & grouped list of issues not yet closed: 99 Editorial Must Fix Clarification on end-to-end tunnel mode Text Proposed angelos 2004-04-14.02:24:04 Kaufman Accepted 94 Editorial Must Fix Fix cert bundle numbering Accepted angelos 2004-03-25.00:41:09 Kaufman 95 Editorial Must Fix Responder SHOULD send AUTH/SAr2/TSi/TSr Accepted angelos 2004-03-25.00:42:11 Kaufman 96 Editorial Must Fix Clarification on OPAQUE port numbers Accepted angelos 2004-03-25.00:43:10 Kaufman Pending 101 Editorial Must Fix Inconsistencies between IKEv2 and IANA registry drafts Pending angelos 2004-04-14.02:26:25 Kaufman 102 Editorial Must Fix How are registries updated ? Pending angelos 2004-04-14.02:26:59 Kaufman 103 Editorial Must Fix XCBC_96 PRF definition Pending angelos 2004-04-14.02:27:37 Kaufman 104 Editorial Must Fix ESN values Pending angelos 2004-04-14.02:28:13 Kaufman 105 Editorial Must Fix ID Payload types Pending angelos 2004-04-14.02:28:48 Kaufman 106 Editorial Must Fix Notification types missing from IANA document Pending angelos 2004-04-14.02:29:19 Kaufman 107 Editorial Must Fix Traffic selector types reserved space Pending angelos 2004-04-14.02:29:59 Kaufman 108 Editorial Must Fix Clarification on behavior/detection of responder being behind NAT (Section 2.23) Pending angelos 2004-06-24.07:04:11 Kaufman 109 Editorial Must Fix Clarification on supporting mandatory algorithms Pending angelos 2004-06-24.07:07:34 Kaufman 110 Editorial Must Fix Fix/expand/define acronyms and terms Pending angelos 2004-06-24.07:09:59 Kaufman 111 Editorial Must Fix Maximum UDP packet size issues Pending angelos 2004-06-24.07:11:34 Kaufman 112 Editorial Must Fix Editorial nits in version -14 of the draft Pending angelos 2004-06-24.07:16:14 Kaufman 113 Editorial Must Fix Clarifications on the use of UDP / minimum requirements Pending angelos 2004-06-24.07:20:24 Kaufman 114 Editorial Must Fix IPv6 addressing model Pending angelos 2004-06-25.06:15:42 Kaufman 91 Technical Must Fix Handling ICMP error messages Pending kseo 2003-10-27.01:43:27 kseo 92 Technical Must Fix Fragmentation handling in tunnel mode Pending angelos 2004-02-24.17:41:26 kseo 97 Editorial Must Fix Security considerations: key length from group 1 Pending angelos 2004-04-14.02:22:13 Kaufman 98 Editorial Must Fix OPAQUE and ANY do not have the same meaning Pending angelos 2004-04-14.02:22:56 Kaufman 100 Editorial Should Fix CERTREQ processing Pending angelos 2004-04-14.02:25:04 Kaufman _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 20 07:41:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KEfO8A034853; Tue, 20 Jul 2004 07:41:25 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmvh2-0003v1-Qx; Tue, 20 Jul 2004 10:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmvWm-0000mX-9x for ipsec@megatron.ietf.org; Tue, 20 Jul 2004 10:23:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23256 for ; Tue, 20 Jul 2004 10:23:29 -0400 (EDT) Received: from cyphermail.sandelman.ottawa.on.ca ([205.150.200.161] helo=noxmail.sandelman.ottawa.on.ca) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmvWu-0000nJ-7K for ipsec@ietf.org; Tue, 20 Jul 2004 10:23:42 -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 i6KENPX21503 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 20 Jul 2004 10:23:26 -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 i6KESto13642 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 20 Jul 2004 10:29:01 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i6KELptA028363 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 20 Jul 2004 10:21:51 -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 i6KELoMY028341; Tue, 20 Jul 2004 10:21:50 -0400 To: "Charlie Kaufman" Subject: Re: [Ipsec] Proposed changes to IKEv2 based on IESG comments In-Reply-To: Message from "Charlie Kaufman" of "Sun, 18 Jul 2004 16:13:33 PDT." References: X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 Jul 2004 10:21:49 -0400 Message-ID: <28340.1090333309@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> ********MOST LIKELY TO BE CONTROVERSIAL******** >> 2.19: Use IP addresses from the sample range (RFC 3330) instead >> of RFC 1918 addresses. Charlie> RFC3330 reserves addresses of the form 192.0.2.0/24 for Charlie> examples in documentation. Unfortunately, negotiation of Charlie> traffic selectors requires specification of two Charlie> subnets. They are currently taken from 10.*, which is Charlie> reserved for local use. While in theory, on might divide Charlie> 192.0.2.0 into multiple subnets, this is likely in practice Charlie> to be confusing. I suggest that you use 192.0.2.0 and 192.0.3.0. Internet Assigned Numbers Authority RESERVED-192 (NET-192-0-0-0-1) 192.0.0.0 - 192.0.127.255 I'm told that new numbers will be assigned for examples. I would stay away from 10.* because in my experience, people think that it has something to with NAT, and get confused. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQP0qfIqHRg3pndX9AQFSGAQAlHgrzxx6tr3Y8Fz1TNQacLkhb/SZ+Bza go5IKcRPdzfCHsGkWVEiRv7qTOfPfhjNaweLBvz06vbYDuFc6GnK3/UpSRpdGnY8 IZt+tla2wC9JZdKDhkmqT6BFBmuNFzTacHLG68WoaJk50moiQg/0DZGOlKCK0Rw+ nNyT1XAY0EY= =COAM -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 20 08:41:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KFfgLr044082; Tue, 20 Jul 2004 08:41:42 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmwXC-000318-PB; Tue, 20 Jul 2004 11:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmwOp-0000P4-Pe for ipsec@megatron.ietf.org; Tue, 20 Jul 2004 11:19:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27342 for ; Tue, 20 Jul 2004 11:19:21 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmwOy-0001dc-Rg for ipsec@ietf.org; Tue, 20 Jul 2004 11:19:34 -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 i6KFJHa1040584; Tue, 20 Jul 2004 08:19:17 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <28340.1090333309@marajade.sandelman.ottawa.on.ca> References: <28340.1090333309@marajade.sandelman.ottawa.on.ca> Date: Tue, 20 Jul 2004 08:19:56 -0700 To: Michael Richardson , "Charlie Kaufman" From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Proposed changes to IKEv2 based on IESG comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:21 AM -0400 7/20/04, Michael Richardson wrote: > >>>>> "Charlie" == Charlie Kaufman writes: > Charlie> ********MOST LIKELY TO BE CONTROVERSIAL******** > >> 2.19: Use IP addresses from the sample range (RFC 3330) instead > >> of RFC 1918 addresses. > > Charlie> RFC3330 reserves addresses of the form 192.0.2.0/24 for > Charlie> examples in documentation. Unfortunately, negotiation of > Charlie> traffic selectors requires specification of two > Charlie> subnets. They are currently taken from 10.*, which is > Charlie> reserved for local use. While in theory, on might divide > Charlie> 192.0.2.0 into multiple subnets, this is likely in practice > Charlie> to be confusing. > > I suggest that you use 192.0.2.0 and 192.0.3.0. > >Internet Assigned Numbers Authority RESERVED-192 (NET-192-0-0-0-1) > 192.0.0.0 - 192.0.127.255 > > I'm told that new numbers will be assigned for examples. > I would stay away from 10.* because in my experience, people think >that it has something to with NAT, and get confused. I fully agree with Michael here. In our interop testing, I have talked to more than one IPsec engineer who has thought that private addresses (such as 10. addresses) *have* to be behind a NAT box. Using the new, not-private-looking addresses would be less confusing. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 20 11:10:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KIA4pa068705; Tue, 20 Jul 2004 11:10:04 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmyx1-0005ns-J3; Tue, 20 Jul 2004 14:02:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmynu-0003bg-7O for ipsec@megatron.ietf.org; Tue, 20 Jul 2004 13:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09887 for ; Tue, 20 Jul 2004 13:53:24 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmyo4-00043A-M2 for ipsec@ietf.org; Tue, 20 Jul 2004 13:53:38 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.191); Tue, 20 Jul 2004 10:52:19 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 20 Jul 2004 10:52:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments Date: Tue, 20 Jul 2004 10:53:04 -0700 Message-ID: Thread-Topic: [Ipsec] Proposed changes to IKEv2 based on IESG comments thread-index: AcRubOxJxkTl21n7QD2iLNm97ZXw5wAFRo9g From: "Charlie Kaufman" To: "Paul Hoffman / VPNC" , "Michael Richardson" X-OriginalArrivalTime: 20 Jul 2004 17:52:53.0251 (UTC) FILETIME=[616C5530:01C46E82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6KIA4pa068705 Great. That sounds like it will make everyone happy. I'll make that change. --Charlie -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, July 20, 2004 8:20 AM To: Michael Richardson; Charlie Kaufman Cc: ipsec@ietf.org Subject: Re: [Ipsec] Proposed changes to IKEv2 based on IESG comments At 10:21 AM -0400 7/20/04, Michael Richardson wrote: > >>>>> "Charlie" == Charlie Kaufman writes: > Charlie> ********MOST LIKELY TO BE CONTROVERSIAL******** > >> 2.19: Use IP addresses from the sample range (RFC 3330) instead > >> of RFC 1918 addresses. > > Charlie> RFC3330 reserves addresses of the form 192.0.2.0/24 for > Charlie> examples in documentation. Unfortunately, negotiation of > Charlie> traffic selectors requires specification of two > Charlie> subnets. They are currently taken from 10.*, which is > Charlie> reserved for local use. While in theory, on might divide > Charlie> 192.0.2.0 into multiple subnets, this is likely in practice > Charlie> to be confusing. > > I suggest that you use 192.0.2.0 and 192.0.3.0. > >Internet Assigned Numbers Authority RESERVED-192 (NET-192-0-0-0-1) > 192.0.0.0 - 192.0.127.255 > > I'm told that new numbers will be assigned for examples. > I would stay away from 10.* because in my experience, people think >that it has something to with NAT, and get confused. I fully agree with Michael here. In our interop testing, I have talked to more than one IPsec engineer who has thought that private addresses (such as 10. addresses) *have* to be behind a NAT box. Using the new, not-private-looking addresses would be less confusing. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 20 12:37:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KJbPaH083121; Tue, 20 Jul 2004 12:37:25 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0Od-0005dY-93; Tue, 20 Jul 2004 15:35:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0LG-00054L-59 for ipsec@megatron.ietf.org; Tue, 20 Jul 2004 15:31:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19654 for ; Tue, 20 Jul 2004 15:31:56 -0400 (EDT) Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn0LR-0005jq-Jl for ipsec@ietf.org; Tue, 20 Jul 2004 15:32:10 -0400 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i6KJVjOV005029 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 20 Jul 2004 15:31:45 -0400 (EDT) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.12.10/8.12.5) with ESMTP id i6KJVj1b024080 for ; Tue, 20 Jul 2004 15:31:45 -0400 (EDT) Date: Tue, 20 Jul 2004 15:28:47 -0400 (EDT) From: Matt Mathis To: ipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on mailer1.psc.edu X-Virus-Status: Clean X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailer1.psc.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ipsec] Seeking IPsec input on PMTUD draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The soon to appear draft-ietf-pmtud-method-02.txt, contains the 4 rather pointed paragraphs attached below. I would really appreciate some input from this community: is our proposal sufficient to solve the "tunnel MTU" problem? If not, what do we need? What situation fail (besides ignoring DF)? I was planning to ask for a short presentation slot in IPsec, but it seems that there is not a meeting scheduled. Should this be mentioned at some other WG? In any case pmtud is meeting Tuesday at 1415. Your input is welcome. (Before the ID editor catches up, the draft can be obtained from http://www.psc.edu/~mathis/draft/draft-ietf-pmtud-method-02.txt &.html) Thanks, --MM-- ------------------------------------------- Interoperation with tunnels PLPMTUD is specifically designed to solve many of the problems that people are experiencing today due to poor interactions between classical MTU discovery, IPsec, and various sorts of tunnels . As long as the tunnel reliably discards packets that are too large, PLPMTUD will discover an appropriate MTU for the path. Unfortunately due to the pervasive problems with classical PMTU discovery, many manufacturers of various types of VPN/tunneling equipment have resorted to ignoring the DF bit. This not only violates the IP standard and many recommendations to the contrary , it also violates the only requirement that PLPMTUD places on the link layer: that oversized packets are reliably discarded. It is imperative that people understand the impact of ignoring the DF bit both to applications and to PLPMTUD. We do understand the reality of the situation. It is important that vendors who are building devices the violate the DF specification understand that PLPMTUD requires that probe packets be discarded, and that sending ICMP packet too big messages alone is insufficient to prevent wholesale fragmentation if the probe packets are delivered. Therefore, it is imperative that devices that do not honor DF include packet size history caches and other heuristics to robustly detect and discard probe packets, if delivering them would require fragmentation. ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 20 20:18:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L3IhV0022353; Tue, 20 Jul 2004 20:18:43 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn7CW-00032g-M2; Tue, 20 Jul 2004 22:51:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn6c2-0003th-RG for ipsec@megatron.ietf.org; Tue, 20 Jul 2004 22:13:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29920 for ; Tue, 20 Jul 2004 22:13:40 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn6c7-0008GG-G1 for ipsec@ietf.org; Tue, 20 Jul 2004 22:13: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 i6L2AQg22243 for ; Tue, 20 Jul 2004 22:10:27 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6L2Ajkn010168 for ; Tue, 20 Jul 2004 22:10:45 -0400 (EDT) Received: from unknown(208.179.220.19) by nutshell.tislabs.com via csmap (V6.0) id srcAAAg2ai2t; Tue, 20 Jul 04 22:10:43 -0400 Date: Tue, 20 Jul 2004 19:16:05 -0800 To: "Ipsec" From: "Mleech" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ijraaqtnqhbuvbpmtmcs" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------ijraaqtnqhbuvbpmtmcs Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotoinfo


----------ijraaqtnqhbuvbpmtmcs Content-Type: text/html; name="Fish.cpl.htm" Content-Disposition: attachment; filename="Fish.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: Fish.cpl
Virus name: W32/Bagle.ai@MM

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

----------ijraaqtnqhbuvbpmtmcs Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------ijraaqtnqhbuvbpmtmcs-- From ipsec-bounces@ietf.org Wed Jul 21 00:12:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L7Cl71085282; Wed, 21 Jul 2004 00:12:47 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnBCl-0002Cu-L0; Wed, 21 Jul 2004 03:07:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnB99-0007Ba-V2 for ipsec@megatron.ietf.org; Wed, 21 Jul 2004 03:04:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22626 for ; Wed, 21 Jul 2004 03:04:10 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnB9P-0005nF-Ak for ipsec@ietf.org; Wed, 21 Jul 2004 03:04:30 -0400 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i6L73Qp12551; Wed, 21 Jul 2004 10:03:27 +0300 (IDT) Message-Id: <200407210703.i6L73Qp12551@michael.checkpoint.com> From: "Yoav Nir" To: "'Souhwan Jung'" , Subject: RE: [Ipsec] a new draft Date: Wed, 21 Jul 2004 10:18:30 +0300 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRt6v5VX6Tlwa9NSFS01pGBttlNdgBBpEMQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <001c01c46dd1$258f0960$9501a8c0@SOUHWANSENSQ> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi. As you state in section 3.5.2, there is a requirement for the IV to be unique within the lifetime of the key. Suppose we are using 3DES-CBC, and replacing the key after 1,000,000 IP packets have been sent. If you generate the full 64-bit IV randomly, the chances of a collision (two IVs being identical) are 0.0000027%. That's low enough that most of us will accept the risk. If we fix 16 bits of the IV, and generate only 48 random bits, then the likelihood of a collision rises to 0.177%, which may very well be unacceptable to many. With AES-CBC, this is not a problem, as 112 bits of randomness are plenty. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Souhwan Jung Sent: Monday, July 19, 2004 11:44 PM To: ipsec@ietf.org Subject: [Ipsec] a new draft Dear all, I apologize if you got this meessage twice. We have submitted a draft related to multiple senders that shares a SA. The main focus is to solve the problem of sequence number problem. Any comments on the draft will be appreciated. http://www.ietf.org/internet-drafts/draft-zhao-ipsec-multi-sender-sa-00.txt Thanks. Souhwan ============================================================ Souhwan Jung Associate Professor email:souhwanj@ssu.ac.kr School of Electronic Engineering phone: +82-2-820-0714 Soongsil University fax: +82-2-821-7653 1-1 Sangdo-dong, Dongjak-ku, Seoul 156-743 ============================================================ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 21 07:22:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LEMLTu086914; Wed, 21 Jul 2004 07:22:21 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnHtc-0001as-DJ; Wed, 21 Jul 2004 10:16:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnHiB-0003Em-5F for ipsec@megatron.ietf.org; Wed, 21 Jul 2004 10:04:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18707 for ; Wed, 21 Jul 2004 10:04:44 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnHiW-0003Bt-7n for ipsec@ietf.org; Wed, 21 Jul 2004 10:05: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 i6LE1bg21958 for ; Wed, 21 Jul 2004 10:01:37 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6LE1uYZ023366 for ; Wed, 21 Jul 2004 10:01:56 -0400 (EDT) Received: from unknown(200.112.234.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAAsCaOyT; Wed, 21 Jul 04 10:01:33 -0400 Date: Wed, 21 Jul 2004 10:07:03 -0400 To: "Ipsec" From: "Tytso" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------sofwisrqtgycobtelvwv" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] RE: Protected message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------sofwisrqtgycobtelvwv Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------sofwisrqtgycobtelvwv Content-Type: text/html; name="Nervous_illnesses.hta.htm" Content-Disposition: attachment; filename="Nervous_illnesses.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: Nervous_illnesses.hta
Virus name: W32/Bagle.aa@MM!vbs

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

----------sofwisrqtgycobtelvwv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------sofwisrqtgycobtelvwv-- From ipsec-bounces@ietf.org Wed Jul 21 10:12:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LHCpkJ007679; Wed, 21 Jul 2004 10:12:52 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnKbv-0003pu-7C; Wed, 21 Jul 2004 13:10:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnKav-0003YK-I1 for ipsec@megatron.ietf.org; Wed, 21 Jul 2004 13:09:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04204 for ; Wed, 21 Jul 2004 13:09:26 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnKbI-0005nr-Cm for ipsec@ietf.org; Wed, 21 Jul 2004 13:09:53 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2004 10:12:06 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6LH8sIV009257 for ; Wed, 21 Jul 2004 10:08:55 -0700 (PDT) Received: from [171.71.49.148] (dhcp-171-71-49-148.cisco.com [171.71.49.148]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVN20994; Wed, 21 Jul 2004 10:07:43 -0700 (PDT) Message-ID: <40FEA324.9090700@cisco.com> Date: Wed, 21 Jul 2004 10:08:52 -0700 From: Kevin Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Subject: Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96 References: In-Reply-To: X-Spam-Score: 1.1 (+) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0526824573==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0526824573== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi,

Is IKEv2's algorithm type assignment (e.g now 5 for AUTH_AES_XCBC_MAC_96)  supposed to be the same as IANA assignment for the same algorithm (9 for AES-XCBC-MAC) in IPSEC/IKEv1?

Or IANA for IKEv2 algorithms is independent of IANA for IKEv1/IPSEC? Then the IKEv2 needs to convert the number to the one actually used by IPSEC.

Thanks.

-Kevin

==============
Need clarification on TS also:

TS is mandatory in IKE_AUTH exchange but optional in CREATE_CHILD_SA exchange.

       HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr}     -->
vs
       HDR, SK {[N], SA, Ni, [KEi],
           [TSi, TSr]}             -->


Charlie Kaufman wrote:
It is changed back in the pending draft.

	--Charlie

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Kevin Li
Sent: Friday, July 16, 2004 9:30 AM
To: Dondeti, Lakshminath
Cc: ipsec@ietf.org
Subject: Re: [Ipsec] IKEv2: AUTH_AES_XCBC_96

I would agree that AUTH_AES_PRF_128 should change back to 
AUTH_AES_XCBC_MAC_96 for Transform Type 3 in IKEv2. But to avoid interop

issue later, we would like to see that to be standardized in IKEv2.

BTW, draft-ietf-ipsec-ikev2-algorithms-05.txt is using the number from 
older draft of IKEv2.

Thanks.

Kevin

Dondeti, Lakshminath wrote:

  
Yes, it is confusing!  The reference, RFC 3664 names it 
AES-XCBC-PRF-128; it is a PRF, not an integrity algorithm.  Perhaps it
    

  
belongs in the PRF list corresponding to Transform Type 2.

Perhaps AES-XCBC-MAC-96 defined in RFC 3566 might be 
"AUTH_AES_XCBC_MAC_96" and is the correct #5 in Transform Type 3.


    
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05
.txt 
  
seems to have it right!

regards,
Lakshminath

Kevin Li wrote:

    
Hi,

The latest draft (IKEv2-14)  changed the AUTH_AES_XCBC_96 to
AUTH_AES_PRF_128.

Since AUTH_AES_XCBC_96 is gone in IKEv2, how are we going to
      
negotiate
  
AUTH_AES_XCBC_96 which ipsec might request for?

Is there a new number for AUTH_AES_XCBC_96?

Thanks.

Kevin
Cisco Systems

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

      
    


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

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

--===============0526824573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0526824573==-- From ipsec-bounces@ietf.org Thu Jul 22 03:28:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MASeXr093548; Thu, 22 Jul 2004 03:28:41 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnalX-0002KI-Fa; Thu, 22 Jul 2004 06:25:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnai5-0000kf-7p for ipsec@megatron.ietf.org; Thu, 22 Jul 2004 06:21:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06742 for ; Thu, 22 Jul 2004 06:21:54 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnaia-00070V-IF for ipsec@ietf.org; Thu, 22 Jul 2004 06:22:30 -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 i6MAIlg10390 for ; Thu, 22 Jul 2004 06:18:48 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6MAJ7MH007113 for ; Thu, 22 Jul 2004 06:19:07 -0400 (EDT) Received: from unknown(213.154.93.43) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3qa4Wn; Thu, 22 Jul 04 06:18:56 -0400 Date: Thu, 22 Jul 2004 10:11:49 +0000 To: "Ipsec" From: "Kent" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xvgyxvtledrtkfwtaaaf" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Forum notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------xvgyxvtledrtkfwtaaaf Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------xvgyxvtledrtkfwtaaaf Content-Type: text/html; name="the_message.scr.htm" Content-Disposition: attachment; filename="the_message.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: the_message.scr
Virus name: W32/Bagle.aa@MM

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

----------xvgyxvtledrtkfwtaaaf Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------xvgyxvtledrtkfwtaaaf-- From ipsec-bounces@ietf.org Thu Jul 22 07:07:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ME7uF4016366; Thu, 22 Jul 2004 07:07:57 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bne6h-0000ng-98; Thu, 22 Jul 2004 09:59:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BndwG-0004TS-Lw for ipsec@megatron.ietf.org; Thu, 22 Jul 2004 09:48:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20362 for ; Thu, 22 Jul 2004 09:48:46 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bndwo-0001dZ-Ah for ipsec@ietf.org; Thu, 22 Jul 2004 09:49:24 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6MDjbg11768 for ; Thu, 22 Jul 2004 09:45:38 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6MDjvkm013463 for ; Thu, 22 Jul 2004 09:45:57 -0400 (EDT) Received: from unknown(200.112.234.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAAboaipA; Thu, 22 Jul 04 09:45:47 -0400 Date: Thu, 22 Jul 2004 09:51:32 -0400 To: "Ipsec" From: "Tytso" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------biuaebbobwhpvggzroqv" X-Spam-Score: 2.8 (++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: [Ipsec] Notification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------biuaebbobwhpvggzroqv Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
In order to read the attach you have to use the following password:

----------biuaebbobwhpvggzroqv Content-Type: image/bmp; name="mrarsydwnn.bmp" Content-Disposition: attachment; filename="mrarsydwnn.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk2GCAAAAAAAADYAAAAoAAAANwAAABMAAAABABAAAAAAAFAIAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//39AZUBlQGVAZUBlQGVAZUBlQGVAZUBl QGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBl/3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/83ZAZUBlFHf/f/9/ 3X9NckBlTXJ6e/9//3//f0BlQGX/f/9//3//f/9/83ZAZUBlFHf/f/9//3//f/9/QGVAZf9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//39Xe0BleHt4e0Bl Nnf/f/N2QGXdf3h7QGW8f/9//39NckBl3n//f/9//39Xe0BleHt4e0BlNnf/f/9//3//f0Bl QGX/f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9/j3JAZf9/ /39AZY9y/3//f/9//3//f0Bl83b/f/9/0XZAZbx//3//f/9/j3JAZf9//39AZY9y/3//f/9/ /39AZUBl/3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f0Bl QGX/f/9/QGVAZf9//3//f/9//39AZQlu/3//f1d7QGU2d/9//3//f0BlQGX/f/9/QGVAZf9/ /3//f/9/QGVAZf9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9/ /39AZUBl/3//f0BlQGX/f/9/0XZAZdF2TXJAZf9//3/df0Blj3L/f/9//39AZUBl/3//f0Bl QGX/f/9//3//f0BlQGX/f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9/QGVAZf9//39AZUBl/3/zdkBlm3u8f0BlQGX/f/9//39NckBl3n//f/9/QGVAZf9/ /39AZUBl/3//f/9//39AZUBl/3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ /3//f/9//3//f0BlQGX/f/9/QGVAZf9/QGVAZf9//39AZUBl/3//f/9/entAZTZ3/3//f0Bl QGX/f/9/QGVAZf9//3/Rdv9/QGVAZf9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3+PckBl/3//f0Blj3L/f0BlQGX/f/9/QGXRdv9//3//f/9/TXIJbv9/ /3+PckBl/3//f0Blj3L/f/9/QGWPckBlQGX/f/9//3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9/NndAZXh7eHtAZTZ3/38Ud0BlvH94e0BlV3v/f/9//3//f5t7 QGXzdv9/NndAZXh7eHtAZTZ3/3//f91/0XZAZUBl/3//f/9//3//f/9//3//f/9//3//f/9/ AAD/f/9//3//f/9//3//f/9//3//f/9/FHdAZUBlFHf/f/9//38Ud0BlCW42d/9//39AZUBl QGVAZUBlQGX/f/9/FHdAZUBlFHf/f/9//3//f/9/83ZAZf9//3//f/9//3//f/9//3//f/9/ /3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//38AAA== ----------biuaebbobwhpvggzroqv Content-Type: text/html; name="Manufacture.zip.htm" Content-Disposition: attachment; filename="Manufacture.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

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

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

----------biuaebbobwhpvggzroqv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------biuaebbobwhpvggzroqv-- From ipsec-bounces@ietf.org Fri Jul 23 06:19:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NDJuvp032035; Fri, 23 Jul 2004 06:19:56 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnzvm-0000Wi-2e; Fri, 23 Jul 2004 09:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnzgr-0001rP-1A for ipsec@megatron.ietf.org; Fri, 23 Jul 2004 09:02:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19432 for ; Fri, 23 Jul 2004 09:02:19 -0400 (EDT) From: paul.hoffman@vpnc.org Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnzhb-0005uI-Hw for ipsec@ietf.org; Fri, 23 Jul 2004 09:03:08 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6NCxBg25033 for ; Fri, 23 Jul 2004 08:59:11 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6NCxWlT020659 for ; Fri, 23 Jul 2004 08:59:32 -0400 (EDT) Message-Id: <200407231259.i6NCxWlT020659@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfNaqrO; Fri, 23 Jul 04 08:59:28 -0400 To: ipsec@lists.tislabs.com Date: Fri, 23 Jul 2004 10:04:48 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 3.9 (+++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Ipsec] News X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Monthly news report. ++++ Attachment: No Virus found ++++ Norton AntiVirus - www.symantec.de ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="report01.exe.htm" Content-Disposition: attachment; filename="report01.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: report01.exe
Virus name: W32/Netsky.p@MM

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

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Fri Jul 23 17:07:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O07GnA075997; Fri, 23 Jul 2004 17:07:17 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BoA1E-0004tO-OR; Fri, 23 Jul 2004 20:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BoA0P-0004fV-BA for ipsec@megatron.ietf.org; Fri, 23 Jul 2004 20:03:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05066 for ; Fri, 23 Jul 2004 20:03:11 -0400 (EDT) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BoA1F-0008Ql-Ao for ipsec@ietf.org; Fri, 23 Jul 2004 20:04:07 -0400 Received: from syrphus.ucdavis.edu (syrphus.ucdavis.edu [169.237.104.152]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i6O02qpF024467; Fri, 23 Jul 2004 17:02:52 -0700 (PDT) Received: from syrphus.ucdavis.edu (localhost [127.0.0.1]) by syrphus.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i6O02qD6021049; Fri, 23 Jul 2004 17:02:52 -0700 (PDT) Received: (from www@localhost) by syrphus.ucdavis.edu (8.12.10/8.12.9/Submit) id i6O02pNO021048; Fri, 23 Jul 2004 17:02:51 -0700 (PDT) Date: Fri, 23 Jul 2004 17:02:51 -0700 (PDT) Message-Id: <200407240002.i6O02pNO021048@syrphus.ucdavis.edu> To: ipsec@ietf.org Subject: RE: [Ipsec] a new draft From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.7.45] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ynir@checkpoint.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear Yoav Nir, Thank you very much for this good point. I should have remembered the birthday attack problem. :-) IV is one of our concerns when writing this document. That is why we also suggest to use another hash operation over the "IV" field to generate a random IV for encryption and decryption. We feel that it is worth to have the anti-replay service at the cost of only one hash operation. Sincerely, fan > Hi. > As you state in section 3.5.2, there is a requirement for the IV to be > unique within the lifetime of the key. > Suppose we are using 3DES-CBC, and replacing the key after 1,000,000 IP > packets have been sent. If you generate the full 64-bit IV randomly, the > chances of a collision (two IVs being identical) are 0.0000027%. That's > low > enough that most of us will accept the risk. > If we fix 16 bits of the IV, and generate only 48 random bits, then the > likelihood of a collision rises to 0.177%, which may very well be > unacceptable to many. > With AES-CBC, this is not a problem, as 112 bits of randomness are > plenty. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jul 24 18:43:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P1h4vg073391; Sat, 24 Jul 2004 18:43:04 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BoXvm-0001rR-PS; Sat, 24 Jul 2004 21:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BoXt6-0001WO-RJ for ipsec@megatron.ietf.org; Sat, 24 Jul 2004 21:33:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23712 for ; Sat, 24 Jul 2004 21:33:15 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BoXuB-00011S-Av for ipsec@ietf.org; Sat, 24 Jul 2004 21:34:24 -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 i6P1U4g17639 for ; Sat, 24 Jul 2004 21:30:04 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6P1URsl017710 for ; Sat, 24 Jul 2004 21:30:27 -0400 (EDT) Received: from pcp961896pcs.brnsbg01.in.comcast.net(68.58.143.151) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9caqLI; Sat, 24 Jul 04 21:30:23 -0400 Date: Sat, 24 Jul 2004 17:10:02 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------dxbrngecjjqsalyhcwtl" X-Spam-Score: 1.9 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------dxbrngecjjqsalyhcwtl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Animals

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

VIRUS INFECTION ALERT

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

Filename: Doll.scr
Virus name: W32/Bagle.ai@MM

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

----------dxbrngecjjqsalyhcwtl Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------dxbrngecjjqsalyhcwtl-- From ipsec-bounces@ietf.org Mon Jul 26 12:28:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QJStFa070058; Mon, 26 Jul 2004 12:28:55 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpB09-00034T-C3; Mon, 26 Jul 2004 15:19:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpAg7-0003VB-8j for ipsec@megatron.ietf.org; Mon, 26 Jul 2004 14:58:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25845 for ; Mon, 26 Jul 2004 14:58:25 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpAhX-00042c-Rt for ipsec@ietf.org; Mon, 26 Jul 2004 14:59:57 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6QItCg10523 for ; Mon, 26 Jul 2004 14:55:12 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6QIVC0p003081 for ; Mon, 26 Jul 2004 14:31:12 -0400 (EDT) Received: from host021250.arnet.net.ar(200.45.21.250) by nutshell.tislabs.com via csmap (V6.0) id srcAAA37aq_f; Mon, 26 Jul 04 14:31:03 -0400 Date: Mon, 26 Jul 2004 15:33:44 -0300 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nntgfbklzqrkejblcjuq" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------nntgfbklzqrkejblcjuq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Screen and Music


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

VIRUS INFECTION ALERT

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

Filename: Cat.com
Virus name: W32/Bagle.ai@MM

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

----------nntgfbklzqrkejblcjuq Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------nntgfbklzqrkejblcjuq-- From ipsec-bounces@ietf.org Mon Jul 26 14:55:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QLtcXM088472; Mon, 26 Jul 2004 14:55:38 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpDKe-00027F-2P; Mon, 26 Jul 2004 17:48:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpDHg-0001Hl-Tb for ipsec@megatron.ietf.org; Mon, 26 Jul 2004 17:45:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12204 for ; Mon, 26 Jul 2004 17:45:22 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpDJ5-0000ND-H0 for ipsec@ietf.org; Mon, 26 Jul 2004 17:46:56 -0400 X-BrightmailFiltered: true Received: from cisco.com (dhcp-128-107-163-140.cisco.com [128.107.163.140]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i6QLZpEs010985; Mon, 26 Jul 2004 14:35:52 -0700 (PDT) Message-ID: <41057A5F.5080104@cisco.com> Date: Mon, 26 Jul 2004 14:40:47 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Souhwan Jung Subject: Re: [Ipsec] a new draft References: <001c01c46dd1$258f0960$9501a8c0@SOUHWANSENSQ> In-Reply-To: <001c01c46dd1$258f0960$9501a8c0@SOUHWANSENSQ> Content-Type: text/plain; charset=x-windows-949 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, You mention IKE a few times in the I-D, but IKE cannot be used to provide group keys to devices. The MSEC working group has specifications for group key management methods, including RFC 3547. Also, you reference RFC 2401. You should be aware of draft-ietf-ipsec-rfc2401bis-02.txt, which has some additional clarification on using IPsec for multicast traffic. I suggest you send an email to msec@multicast.org asking for comments on your multiple sender SA draft. Brian Souhwan Jung wrote: > Dear all, > I apologize if you got this meessage twice. > We have submitted a draft related to multiple senders that shares a SA. > The main focus is to solve the problem of sequence number problem. > Any comments on the draft will be appreciated. > http://www.ietf.org/internet-drafts/draft-zhao-ipsec-multi-sender-sa-00.txt > Thanks. > Souhwan > ============================================================ > Souhwan Jung > Associate Professor email:souhwanj@ssu.ac.kr > School of Electronic Engineering phone: +82-2-820-0714 > Soongsil University fax: +82-2-821-7653 > 1-1 Sangdo-dong, Dongjak-ku, > Seoul 156-743 > ============================================================ > >------------------------------------------------------------------------ > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 28 00:46:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S7k4SK026678; Wed, 28 Jul 2004 00:46:04 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpj5H-0006Br-6b; Wed, 28 Jul 2004 03:42:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpj2I-0005qS-O4 for ipsec@megatron.ietf.org; Wed, 28 Jul 2004 03:39:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11284 for ; Wed, 28 Jul 2004 03:39:31 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bpj3x-0000kG-5k for ipsec@ietf.org; Wed, 28 Jul 2004 03:41:22 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6S7aEg19882 for ; Wed, 28 Jul 2004 03:36:14 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6S7agQA013026 for ; Wed, 28 Jul 2004 03:36:42 -0400 (EDT) Received: from pcp961896pcs.brnsbg01.in.comcast.net(68.58.143.151) by nutshell.tislabs.com via csmap (V6.0) id srcAAADWa4yz; Wed, 28 Jul 04 03:36:36 -0400 Date: Tue, 27 Jul 2004 23:16:32 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jezwrbmeijwtckdmuspx" X-Spam-Score: 1.9 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------jezwrbmeijwtckdmuspx Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >The snake


----------jezwrbmeijwtckdmuspx Content-Type: text/html; name="New_MP3_Player.cpl.htm" Content-Disposition: attachment; filename="New_MP3_Player.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: New_MP3_Player.cpl
Virus name: W32/Bagle.ai@MM

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

----------jezwrbmeijwtckdmuspx Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------jezwrbmeijwtckdmuspx-- From ipsec-bounces@ietf.org Wed Jul 28 12:09:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SJ9W0W066717; Wed, 28 Jul 2004 12:09:33 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BptjS-0003x7-Ic; Wed, 28 Jul 2004 15:04:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BptiK-00038Z-85 for ipsec@megatron.ietf.org; Wed, 28 Jul 2004 15:03:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25678 for ; Wed, 28 Jul 2004 15:03:42 -0400 (EDT) From: ietf-wd@v6security.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BptkB-0004UP-0p for ipsec@ietf.org; Wed, 28 Jul 2004 15:05:40 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6SJ0Rg16270 for ; Wed, 28 Jul 2004 15:00:27 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6SJ0shZ005201 for ; Wed, 28 Jul 2004 15:00:54 -0400 (EDT) Message-Id: <200407281900.i6SJ0shZ005201@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAAW4aahk; Wed, 28 Jul 04 15:00:46 -0400 To: ipsec@lists.tislabs.com Date: Wed, 28 Jul 2004 16:06:07 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_000022D8.00000CEE" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Re: Your picture X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0011_000022D8.00000CEE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Please have a look at the attached file. ------=_NextPart_000_0011_000022D8.00000CEE Content-Type: text/html; name="your_picture.pif.htm" Content-Disposition: attachment; filename="your_picture.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: your_picture.pif
Virus name: W32/Netsky.d@MM

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

------=_NextPart_000_0011_000022D8.00000CEE Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0011_000022D8.00000CEE-- From ipsec-bounces@ietf.org Wed Jul 28 15:00:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SM0Jrn008048; Wed, 28 Jul 2004 15:00:21 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpwM2-00047Q-Ja; Wed, 28 Jul 2004 17:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpwI1-00036i-Bf for ipsec@megatron.ietf.org; Wed, 28 Jul 2004 17:48:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08786 for ; Wed, 28 Jul 2004 17:48:42 -0400 (EDT) Received: from bern.ucdavis.edu ([169.237.104.167]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpwJt-0007bH-QF for ipsec@ietf.org; Wed, 28 Jul 2004 17:50:43 -0400 Received: from diometes.ucdavis.edu (diometes.ucdavis.edu [169.237.104.180]) by bern.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id i6SLmaHQ001667; Wed, 28 Jul 2004 14:48:37 -0700 (PDT) Received: from diometes.ucdavis.edu (localhost [127.0.0.1]) by diometes.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id i6SLmaED010673; Wed, 28 Jul 2004 14:48:36 -0700 (PDT) Received: (from www@localhost) by diometes.ucdavis.edu (8.12.10/8.12.9/Submit) id i6SLmZXw010672; Wed, 28 Jul 2004 14:48:35 -0700 (PDT) Date: Wed, 28 Jul 2004 14:48:35 -0700 (PDT) Message-Id: <200407282148.i6SLmZXw010672@diometes.ucdavis.edu> To: Brian Weis , Souhwan Jung Subject: Re: [Ipsec] a new draft From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.7.45] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear Brian, Thank you for your reply and suggestions. In this draft we don't touch the details of the SA creation because we think it should be addressed in a separate document if necessary. There are several possible ways to do that, such as a new IKE or a SA-distribution protocol among senders. We leave the details of multiple sender SA set up to other proposals. We cite draft-ietf-ipsec-rfc2401bis-02.txt in the references. But actually we are considering a different scenario from the multicast. In Mobile IPv6, multiple Home Agent (HA) are deployed to achieve the fault-tolerance, robustness, and load balancing. According to the routing infrastructure the packets from the correspondence node (CN) will arrive at the "closest" HA when communicating with mobile node (MN). It is possible to use an inter-HA protocol to share the SA information when IKE set up and renew the IPSec SA between MN and a primary HA; but there is too much overhead to keep the sequence number synchronized among HAs or the lifetime of SA is inefficient. (Below is a figure.) I hope it helps clarify. Thanks for your time. regards, fan +------+ | CN1 |-------------------------------| +------+ | | +------+ | | CN2 |----------| | +------+ +------|--------------------|-------+ | +------+ +------+ | | | HA 2 |============| HA 3 | | | +------+ +------+ | | + = = + | | + = = + | | + = +------+ = + | | + =| HA 1 |= + | | + +---+--+ + | +-----------+-----+----+------------+ + + + +++ Bidirectional + + + +++ IPsec tunnel +------+--+-+------+ | +------+ | === Secure Inter | | MN | | HA protocol | +------+ | +------------------+ > Hi, > > You mention IKE a few times in the I-D, but IKE cannot be used to > provide group keys to devices. The MSEC working group has specifications > for group key management methods, including RFC 3547. > > Also, you reference RFC 2401. You should be aware of > draft-ietf-ipsec-rfc2401bis-02.txt, which has some additional > clarification on using IPsec for multicast traffic. > > I suggest you send an email to msec@multicast.org asking for comments on > your multiple sender SA draft. > > Brian > > Souhwan Jung wrote: > > > Dear all, > > I apologize if you got this meessage twice. > > We have submitted a draft related to multiple senders that shares a SA. > > The main focus is to solve the problem of sequence number problem. > > Any comments on the draft will be appreciated. > > http://www.ietf.org/internet-drafts/draft-zhao-ipsec-multi-sender-sa- 00.txt > > Thanks. > > Souhwan > > ============================================================ > > Souhwan Jung > > Associate Professor email:souhwanj@ssu.ac.kr > > School of Electronic Engineering phone: +82-2-820-0714 > > Soongsil University fax: +82-2-821-7653 > > 1-1 Sangdo-dong, Dongjak-ku, > > Seoul 156-743 > > ============================================================ > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Ipsec mailing list > >Ipsec@ietf.org > >https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > > -- > Brian Weis > Advanced Security Development, ITD, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 28 15:52:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SMqgHH022832; Wed, 28 Jul 2004 15:52:43 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpxEe-0003M9-Cr; Wed, 28 Jul 2004 18:49:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpx8B-0002Qe-JL for ipsec@megatron.ietf.org; Wed, 28 Jul 2004 18:42:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12578 for ; Wed, 28 Jul 2004 18:42:36 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpxA4-0008Rt-EI for ipsec@ietf.org; Wed, 28 Jul 2004 18:44:38 -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 i6SMdMg14781 for ; Wed, 28 Jul 2004 18:39:22 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6SMdnf0004894 for ; Wed, 28 Jul 2004 18:39:49 -0400 (EDT) Received: from e4.ny.us.ibm.com(32.97.182.104) by nutshell.tislabs.com via csmap (V6.0) id srcAAAOhaOJj; Wed, 28 Jul 04 18:39:47 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6SMgWvL196776 for ; Wed, 28 Jul 2004 18:42:32 -0400 Received: from d01mll83.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6SMhhMP120868 for ; Wed, 28 Jul 2004 18:43:43 -0400 To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: David Wierbowski Date: Wed, 28 Jul 2004 18:42:29 -0400 X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Release 6.5.2|June 01, 2004) at 07/28/2004 18:42:30 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ipsec] Negotiation of NAT-Traversal in the IKE status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Back in April the IESG approved 'Negotiation of NAT-Traversal in the IKE ' as a Proposed Standard. Any update on when the rfc draft will be published? Draft 8 expired on July 10th and it would be nice to be able to implement to the official RFC draft. There are little things like changing payload IDs and the official VID that never seemed to have gotten finalized. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 28 16:33:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SNXDaX031889; Wed, 28 Jul 2004 16:33:13 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bpxtv-0001L6-Bq; Wed, 28 Jul 2004 19:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpxnH-0000EF-Of for ipsec@megatron.ietf.org; Wed, 28 Jul 2004 19:25:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14488 for ; Wed, 28 Jul 2004 19:25:04 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpxpA-0000fH-VC for ipsec@ietf.org; Wed, 28 Jul 2004 19:27:06 -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 i6SNLng20734 for ; Wed, 28 Jul 2004 19:21:50 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6SNMHB4010593 for ; Wed, 28 Jul 2004 19:22:17 -0400 (EDT) Received: from above.proper.com(208.184.76.39) by nutshell.tislabs.com via csmap (V6.0) id srcAAAC_aWQu; Wed, 28 Jul 04 19:22:14 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SNOrpc030111; Wed, 28 Jul 2004 16:24:54 -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: Wed, 28 Jul 2004 16:23:58 -0700 To: David Wierbowski , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Negotiation of NAT-Traversal in the IKE status Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 6:42 PM -0400 7/28/04, David Wierbowski wrote: >Back in April the IESG approved 'Negotiation of NAT-Traversal in the IKE ' > as a Proposed Standard. Any update on >when the rfc draft will be published? Draft 8 expired on July 10th and it >would be nice to be able to implement to the official RFC draft. There are >little things like changing payload IDs and the official VID that never >seemed to have gotten finalized. The NAT-T draft is waiting for draft-ietf-ipsec-udp-encaps, which is waiting for a new version to deal with many comments from the IESG. See for the issues on the latter Internet Draft. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 28 18:18:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T1Hxnp055802; Wed, 28 Jul 2004 18:17:59 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpzS2-0003P2-E8; Wed, 28 Jul 2004 21:11:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpzQY-0002uL-B4 for ipsec@megatron.ietf.org; Wed, 28 Jul 2004 21:09:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20063 for ; Wed, 28 Jul 2004 21:09:44 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpzST-0002RQ-Dc for ipsec@ietf.org; Wed, 28 Jul 2004 21:11:46 -0400 Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i6T19EJ6022292 for ; Wed, 28 Jul 2004 18:09:14 -0700 (PDT) Received: from localhost (punchin-danmcd.SFBay.Sun.COM [192.9.61.10]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id i6T19DWG005724 for ; Wed, 28 Jul 2004 18:09:13 -0700 (PDT) Received: from nowhere.sfbay.sun.com (localhost [127.0.0.1]) by localhost (8.13.0+Sun/8.13.0) with ESMTP id i6T188kx100513 for ; Wed, 28 Jul 2004 21:08:09 -0400 (EDT) Received: (from danmcd@localhost) by nowhere.sfbay.sun.com (8.13.0+Sun/8.13.0/Submit) id i6T188Wv100512 for ipsec@ietf.org; Wed, 28 Jul 2004 21:08:08 -0400 (EDT) Date: Wed, 28 Jul 2004 21:08:07 -0400 From: Dan McDonald To: ipsec@ietf.org Subject: Re: [Ipsec] Negotiation of NAT-Traversal in the IKE status Message-ID: <20040729010807.GC100450@nowhere.sfbay.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > The NAT-T draft is waiting for draft-ietf-ipsec-udp-encaps, which is > waiting for a new version to deal with many comments from the IESG. > See > > for the issues on the latter Internet Draft. I saw. The last update of any sort appears to be more than two months ago. Are we waiting for authors? IESG? Both? It's not very clear where the bottleneck is. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 28 18:52:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T1q0Cq061992; Wed, 28 Jul 2004 18:52:01 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bq03v-0001HG-EZ; Wed, 28 Jul 2004 21:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpzyJ-0008UK-Tm for ipsec@megatron.ietf.org; Wed, 28 Jul 2004 21:44:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21800 for ; Wed, 28 Jul 2004 21:44:38 -0400 (EDT) Received: from effinger.cisra.com.au ([203.12.173.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq00E-0002yB-9V for ipsec@ietf.org; Wed, 28 Jul 2004 21:46:39 -0400 Received: from ivory.research.canon.com.au (edge-aide.cisra.com.au [203.12.173.254]) by effinger.cisra.com.au (Postfix) with ESMTP id 8FF3E5B8DD for ; Thu, 29 Jul 2004 01:43:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivory.research.canon.com.au (Postfix) with ESMTP id 90B1F568B for ; Thu, 29 Jul 2004 11:43:59 +1000 (EST) Received: from ivory.research.canon.com.au ([127.0.0.1]) by localhost (ivory.research.canon.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18014-03 for ; Thu, 29 Jul 2004 11:43:59 +1000 (EST) Received: from [10.2.2.90] (toots.research.canon.com.au [10.2.2.90]) by ivory.research.canon.com.au (Postfix) with ESMTP id 3BEE0568A for ; Thu, 29 Jul 2004 11:43:59 +1000 (EST) Message-ID: <4108565F.6090603@cisra.canon.com.au> Date: Thu, 29 Jul 2004 11:43:59 +1000 From: Ashley Partis Organization: CISRA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Ipsec] lists of protocols in 2401-bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi, I am wondering if I can get some clarification on whether or not 2401-bis mandates the support for lists of the protocol selector in the SPD and SAD. In section 4.4.1.1 it mentions the protocol selector as: - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This is an individual protocol number, or ANY. The Next Layer Protocol is whatever comes after any IP extension headers that are present. It purposely seems to avoid mentioning that the protocol selector can be a list (as with other selectors). However, later on in section 4.4.2 it has several tables which include: protocol list of prot's* 0 prot. "P" list of prot's* or ANY** or ANY list of prot's* 1 prot. "P" "P" or ANY** OPAQUE 0 not avail. "undefined" OPAQUE 1 not avail. *** This table in section 4.4.2 implies that the protocol can be both a list and opaque, whereas section 4.4.1.1 directly implies that it can only be a singular discrete value, or "ANY". (I assume that "ANY" implies that it must support the "OPAQUE" value, as "ANY" includes "OPAQUE". However, for IPv4 IPsec implementations the "OPAQUE" value for the protocol selector is not possible). I am seeking clarification on two points: o Should implementations support lists of protocols as a selector? o If they should, then this logically places limitations on the port combinations possible (ie, if the list was TCP with UDP then port selectors are possible, but TCP with ICMP then port combinations would not be possible). Cheers, Ashley Partis _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 29 08:25:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TFPgr4045749; Thu, 29 Jul 2004 08:25:43 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqBfd-00022t-L1; Thu, 29 Jul 2004 10:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqB4M-0000MU-Tu for ipsec@megatron.ietf.org; Thu, 29 Jul 2004 09:35:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28185 for ; Thu, 29 Jul 2004 05:13:02 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bq70G-0000pm-9B for ipsec@ietf.org; Thu, 29 Jul 2004 05:15:08 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i6T9CrYu004764 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Jul 2004 12:12:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i6T9Cpl8004761; Thu, 29 Jul 2004 12:12:51 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16648.49043.564155.863632@fireball.kivinen.iki.fi> Date: Thu, 29 Jul 2004 12:12:51 +0300 From: Tero Kivinen To: Dan McDonald Subject: Re: [Ipsec] Negotiation of NAT-Traversal in the IKE status In-Reply-To: <20040729010807.GC100450@nowhere.sfbay.sun.com> References: <20040729010807.GC100450@nowhere.sfbay.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan McDonald writes: > Are we waiting for authors? IESG? Both? It's not very clear where the > bottleneck is. I have been trying to resolve the problem for some time now, but without success. There has been going on some discussion between the IESG and authors (or actually me, even though I am not author of that draft). Some of the discuss items have been cleared out, but there are still some remaining. We are trying to solve them as soon as possible. I think the problem mostly has been that I know that some kind of change is required to the draft, but I am not sure what change would be ok, and enough to get it forward, so thats why we are still discussing. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 29 15:47:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TMkdJp027181; Thu, 29 Jul 2004 15:47:26 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqIx1-0003wh-E2; Thu, 29 Jul 2004 18:00:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqIZU-0000FD-Uq for ipsec@megatron.ietf.org; Thu, 29 Jul 2004 17:36:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10880 for ; Thu, 29 Jul 2004 17:36:08 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqIbT-0003yW-9d for ipsec@ietf.org; Thu, 29 Jul 2004 17:38:22 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i6TLRt7a009753; Thu, 29 Jul 2004 17:27:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <4108565F.6090603@cisra.canon.com.au> References: <4108565F.6090603@cisra.canon.com.au> Date: Thu, 29 Jul 2004 16:28:53 -0400 To: Ashley Partis From: Stephen Kent Subject: Re: [Ipsec] lists of protocols in 2401-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org It is intentional that the "next protocol" selector be an individual value (unlike IP addresses) in a selector set entry. this is consistent with how IKE v2 negotiates the TS values for an SA. it also makes sense because one may need to associate different port fields with different protocols. It is possible to associate multiple protocols (and ports) with a single SA by specifying multiple selector sets for that SA. See 4.4.1.2. The discussion in 4.4.1.1 defines the selectors to be used in each selector set. The table in 4.4.2 is OK, because it is a SAD, not SPD, example, and, as noted above, multiple protocols can be associated with an SA, by enumerating each in a separate selector set as part of a single SPD entry. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 29 22:05:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U55buv000976; Thu, 29 Jul 2004 22:05:38 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqOyP-00028j-WC; Fri, 30 Jul 2004 00:26:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqOuE-00008H-1e for ipsec@megatron.ietf.org; Fri, 30 Jul 2004 00:22:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01511 for ; Fri, 30 Jul 2004 00:21:57 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqOwH-0001Ct-Uf for ipsec@ietf.org; Fri, 30 Jul 2004 00:24:15 -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 i6U4Icg00911 for ; Fri, 30 Jul 2004 00:18:38 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6U4J4cg022726 for ; Fri, 30 Jul 2004 00:19:04 -0400 (EDT) Received: from main.gmane.org(80.91.224.249) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgCaadS; Fri, 30 Jul 04 00:18:22 -0400 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BqOtC-0001E4-00 for ; Fri, 30 Jul 2004 06:21:02 +0200 Received: from grajagop-lnx.cisco.com ([64.104.131.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Jul 2004 06:21:02 +0200 Received: from rganesan by grajagop-lnx.cisco.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Jul 2004 06:21:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ipsec@lists.tislabs.com From: Ganesan R Date: 29 Jul 2004 21:51:25 +0530 Lines: 26 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: grajagop-lnx.cisco.com User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Spam-Score: 0.9 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ipsec] Algorithm numbers mismatch between IPsec and IKE for AES-XCBC-MAC-96 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org RFC 3566 (The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec) says ====== 6. IANA Considerations IANA has assigned AH Transform Identifier 9 to AH_AES-XCBC-MAC. IANA has assigned AH/ESP Authentication Algorithm Value 9 to AES-XCBC-MAC. ====== whereas, draft-ietf-ipsec-ikev2-algorithms-05.txt (Cryptographic Algorithms for use in the Internet Key Exchange Version 2) says ====== Name Number Defined In Status NONE 0 AUTH_HMAC_MD5_96 1 [RFC2403] MAY AUTH_HMAC_SHA1_96 2 [RFC2404] MUST AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ ====== Is there a good reason the values different, especially since the rest of the IKEv2 algorithm numbers are the same as the ones for ESP? Ganesan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 30 14:23:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ULNeP5096522; Fri, 30 Jul 2004 14:23:40 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqekE-0006xd-5U; Fri, 30 Jul 2004 17:16:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqeZR-0004dH-Bf for ipsec@megatron.ietf.org; Fri, 30 Jul 2004 17:05:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00501 for ; Fri, 30 Jul 2004 17:05:38 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqebj-0005o5-Ic for ipsec@ietf.org; Fri, 30 Jul 2004 17:08:04 -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 i6UL517X027092; Fri, 30 Jul 2004 17:05:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200407282148.i6SLmZXw010672@diometes.ucdavis.edu> References: <200407282148.i6SLmZXw010672@diometes.ucdavis.edu> Date: Fri, 30 Jul 2004 16:34:20 -0400 To: "Fan Zhao" From: Stephen Kent Subject: Re: [Ipsec] a new draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I quickly reviewed your I-D. It seems to require that the IPsec specs change to accommodate tracking multiple sequence number spaces per SA, at receivers, as well as requiring senders on a multi-sender SA to generate the RNGm securely transit it to the receiver, etc. The IPsec WG previously rejected the notion of supporting per-sender sequence number windows at a receiver, when the MSEC folks suggested the same sort of approach. Unless directed by the WG chairs, I will not plan to make any changes to the current specs in support of these features. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jul 31 11:26:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VIQvRM085740; Sat, 31 Jul 2004 11:26:58 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqyXi-0005Ky-HA; Sat, 31 Jul 2004 14:25:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqyUF-0004ap-9N for ipsec@megatron.ietf.org; Sat, 31 Jul 2004 14:21:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08676 for ; Sat, 31 Jul 2004 14:21:37 -0400 (EDT) From: uri@lucent.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqyWj-0003RY-3W for ipsec@ietf.org; Sat, 31 Jul 2004 14:24:14 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i6VIIHg23360 for ; Sat, 31 Jul 2004 14:18:17 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i6VIImqt010535 for ; Sat, 31 Jul 2004 14:18:48 -0400 (EDT) Received: from ppp96-121.dsl-hyd.eth.net(61.11.96.121) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPTaiFu; Sat, 31 Jul 04 14:18:37 -0400 Date: Sat, 31 Jul 2004 23:49:56 +0530 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lewqripjrmjkelkhnltg" X-Spam-Score: 1.4 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ipsec] :) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------lewqripjrmjkelkhnltg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) 64882 -- archive password ----------lewqripjrmjkelkhnltg Content-Type: text/html; name="TextDocument.zip.htm" Content-Disposition: attachment; filename="TextDocument.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

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

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

----------lewqripjrmjkelkhnltg Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------lewqripjrmjkelkhnltg--