From ipsec-bounces@ietf.org Fri Oct 1 01:42:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09279 for ; Fri, 1 Oct 2004 01:42:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDG57-00080J-NS; Fri, 01 Oct 2004 01:35:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFu2-0004P1-DT for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 01:24:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08000 for ; Fri, 1 Oct 2004 01:24:21 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDG2P-0005dx-Nc for ipsec@ietf.org; Fri, 01 Oct 2004 01:33:03 -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 i915Nnjf018961; Fri, 1 Oct 2004 01:23:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <20040929021440.GD435@thunk.org> References: <20040929021440.GD435@thunk.org> Date: Fri, 1 Oct 2004 01:26:49 -0400 To: "Theodore Ts'o" From: Karen Seo Subject: Re: [Ipsec] Minor typographical errors in draft-ietf-ipsec-rfc2401bis-03.txt 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: 0ddefe323dd869ab027dbfff7eff0465 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 Thank you. >While going through the rfc2401bis-03 draft, I found the following >minor typo's. > > - Ted > >Page 12, Section 4.1: Extra curly brace: > > 1. Search the SAD for a match on the combination of SPI, > destination address, and source address}. If an SAD entry > matches, then process the inbound ESP packet with that > >If you're removing the curly brace syntax and replacing it with >explantory text, then you should probably also make the change from >{SPI} to SPI here: > > 3. Search the SAD for a match on only {SPI} if the receiver has > chosen to maintain a single SPI space for AH and ESP, and on > both SPI and protocol otherwise. If an SAD entry matches then > process the inbound ESP packet with that matching SAD entry. > Otherwise, discard the packet and log an auditable event. > >-------------------------------- >Page 13: > >Extra hyphen in "-support"? > > Therefore a sender SHOULD put traffic of different classes, but with > the same selector values, on different SAs to -support QoS > appropriately. To permit this, the IPsec implementation MUST permit > establishment and maintenance of multiple SAs between a given sender > >-------------------------------- > >Section 4.4, Page 18: > >Missing period at the end of this paragraph: > > depend on the kind and number of extension headers present. The > "initial" fragment might not be the first fragment, in this > context > > > >_______________________________________________ >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 mailman-bounces@ietf.org Fri Oct 1 06:27:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14737 for ; Fri, 1 Oct 2004 06:27:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJev-0001Ln-OF for ipsec-archive@lists.ietf.org; Fri, 01 Oct 2004 05:25:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipsec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:09:02 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipsec-archive@lists.ietf.org: List Password // URL ---- -------- ipsec@ietf.org ogcewi https://www1.ietf.org/mailman/options/ipsec/ipsec-archive%40lists.ietf.org From ipsec-bounces@ietf.org Fri Oct 1 13:13:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26448 for ; Fri, 1 Oct 2004 13:13:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQAA-0007Qo-6Y; Fri, 01 Oct 2004 12:21:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDODf-0001d5-NZ for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 10:17:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03199 for ; Fri, 1 Oct 2004 10:17:09 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOM8-0008Af-Es for ipsec@ietf.org; Fri, 01 Oct 2004 10:25:56 -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 i91E95jh003252; Fri, 1 Oct 2004 10:09:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200409302331.i8UNV5Sj099207@givry.rennes.enst-bretagne.fr> References: <200409302331.i8UNV5Sj099207@givry.rennes.enst-bretagne.fr> Date: Fri, 1 Oct 2004 10:05:48 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Francis, >=> I have no problem with the decorrelation idea (I began with pattern >matching and term rewriting systems where the problem is hard, BTW >IMHO decorrelation is related to completion, i.e., Knuth-Bendix algorithm). > But I still believe a statement explaining the SPD is considered as >being decorrelated after the end of 4.4.1 should be fine. > > >=> so the SAD check works for the first example but not (yet) for the > >second where the rule 2 is added* after the creation of the SAD entry > >for the rule 1 (*: after in time, before in order). > > section 4.4.1 concludes with a brief section: > > Handling Changes to the SPD while the System is Running > > If a change is made to the SPD while the system is running, a check > SHOULD be made of the effect of this change on extant SAs. An > implementation MAY choose to check the impact of an SPD change on > extant SAs and to provide a user/administrator with a mechanism for > configuring what actions to take, e.g., delete an affected SA, allow > an affected SA to continue unchanged, etc. > > i think this addressed your concern. > >=> yes but this conflicts with the end of 4.4.2: > > For each of the selectors defined in Section 4.4.1.1, the entry for > an inbound SA in the SAD MUST contain the value or values negotiated > at the time the SA was created. For a receiver, these values are used > to check that the header fields of an inbound packet (after IPsec > processing) match the selector values negotiated for the SA. For the > receiver, this is part of verifying that a packet arriving on an SA > is consistent with the policy for the SA. (See Section 6 for rules > for ICMP messages.) These fields can have the form of specific > values, ranges, ANY, or OPAQUE, as described in section 4.4.1.1, > "Selectors." > >(note I like the idea of explaining that the SAD selectors are in fact >the inbound SPD cache!) We will note explicitly that the SAD acts as a cache for selector checking for inbound traffic on SAs. However, I do not see why you feel that the 4.4.2 text conflicts with the text at the end of 4.4.1. The 4.4.2 text is a steady state discussion of processing. The text at the end of 4.4.1 is an exception processing discussion. > > > 5.1.2.2: other than for covert channel concerns, why would one never > > copy a flow label from the inner header? > > > >=> in order to break the unicity rule on flow labels? IMHO the flow > >label MUST NOT be copied. > > what is the "unicity rule?" > >=> RFC 3697 section 3 (flow labeling requirements): > > A source node MUST ensure that it does not unintentionally reuse Flow > Label values it is currently using or has recently used when creating > new flows. Flow Label values previously used with a specific pair of > source and destination addresses MUST NOT be assigned to new flows > with the same address pair within 120 seconds of the termination of > the previous flow. > >Obviously RFC 3697 requires the source node has the control of label >assignment and bans SGs from copying flow labels from inner headers. OK, I see the problem now. The SG, if it copied flow labels could cause collisions because it appears as the new source and the sources behind it might use the same flow label for their own flows. >PS: about flow labels IMHO it is enough to refer to RFC 3697. >The only issue is the RFC 3697 doesn't really define flows: > > A flow is a sequence of packets sent from a particular source to a > particular unicast, anycast, or multicast destination that the source > desires to label as a flow. A flow could consist of all packets in a > specific transport connection or a media stream. However, a flow is > not necessarily 1:1 mapped to a transport connection. > >I believe we can say: > - a SA can form a flow (default case) > - multiple instances of SAs with the same parameters can form a flow > (at least two reasons: keep the same flow label across rekeying, > allow explicit specification of flow label values) >so we get: > - zero flow label > - explicit specification (which includes previous case) > - automatic assignment by the IPv6 according to its own flow establishment > method (i.e., don't care at the IPsec level :-) >This can be encoded by an optional value on 20 bits. OK. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 1 13:43:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29571 for ; Fri, 1 Oct 2004 13:43:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQpT-00042Z-Ml; Fri, 01 Oct 2004 13:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPws-0007tD-Mq for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 12:07: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 MAA17392 for ; Fri, 1 Oct 2004 12:07:56 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQ5M-00023g-9m for ipsec@ietf.org; Fri, 01 Oct 2004 12:16:44 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i91G76j03629; Fri, 1 Oct 2004 18:07:06 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i91G76Sj002852; Fri, 1 Oct 2004 18:07:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410011607.i91G76Sj002852@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) In-reply-to: Your message of Fri, 01 Oct 2004 10:05:48 EDT. Date: Fri, 01 Oct 2004 18:07:06 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: > section 4.4.1 concludes with a brief section: > > Handling Changes to the SPD while the System is Running > > If a change is made to the SPD while the system is running, a check > SHOULD be made of the effect of this change on extant SAs. An > implementation MAY choose to check the impact of an SPD change on > extant SAs and to provide a user/administrator with a mechanism for > configuring what actions to take, e.g., delete an affected SA, allow > an affected SA to continue unchanged, etc. > > i think this addressed your concern. > >=> yes but this conflicts with the end of 4.4.2: > > For each of the selectors defined in Section 4.4.1.1, the entry for > an inbound SA in the SAD MUST contain the value or values negotiated > at the time the SA was created. For a receiver, these values are used > to check that the header fields of an inbound packet (after IPsec > processing) match the selector values negotiated for the SA. For the > receiver, this is part of verifying that a packet arriving on an SA > is consistent with the policy for the SA. (See Section 6 for rules > for ICMP messages.) These fields can have the form of specific > values, ranges, ANY, or OPAQUE, as described in section 4.4.1.1, > "Selectors." > >(note I like the idea of explaining that the SAD selectors are in fact >the inbound SPD cache!) We will note explicitly that the SAD acts as a cache for selector checking for inbound traffic on SAs. => fine. However, I do not see why you feel that the 4.4.2 text conflicts with the text at the end of 4.4.1. => a possible action of the end of 4.4.1 is to update the selectors of an affected SA, this is forbiden by the MUST of 4.4.2. IMHO the problem is in the wording, i.e., "contain" should be changed by "be filled by" or something else catching the idea the selectors are dynamic and *always* reflect the SPD as a cache does. The 4.4.2 text is a steady state discussion of processing. The text at the end of 4.4.1 is an exception processing discussion. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 1 14:01:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01848 for ; Fri, 1 Oct 2004 14:01:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRS3-0001mU-Gt; Fri, 01 Oct 2004 13:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQru-0005ed-PV for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 13:06:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25325 for ; Fri, 1 Oct 2004 13:06:52 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR0O-0003kh-4s for ipsec@ietf.org; Fri, 01 Oct 2004 13:15:41 -0400 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i91H1rd04738 for ; Fri, 1 Oct 2004 13:01:53 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i91H3nDc017710 for ; Fri, 1 Oct 2004 13:03:49 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAArPaaKI; Fri, 1 Oct 04 13:03:46 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i91H6OJ01767; Fri, 1 Oct 2004 10:06:24 -0700 (PDT) Message-ID: <415D8F01.9010807@isi.edu> Date: Fri, 01 Oct 2004 10:08:17 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christian Noel" X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ipsec] FYI - RFC3884 and some notes on 2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1019480178==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1019480178== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE6BB6D77E9147D3523468B5E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE6BB6D77E9147D3523468B5E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI, the following RFC has (finally) been issued. (it might be useful to cite it in sec 4.1 @end pg 12/beg pg 13, sec 13 top pg 62, & end sec D.3 of RFC2401bis, e.g.): 3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L. Eggert, Y. Wang. September 2004. (Format: TXT=59437 bytes) (Status: INFORMATIONAL) Joe --------------enigE6BB6D77E9147D3523468B5E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBXY8FE5f5cImnZrsRAt5EAJ9zwe4vU/q1BvGhlm2UJbn1zCly5QCg2n/k VOrMPLNI+vtaarAP7SH2NOo= =LbUB -----END PGP SIGNATURE----- --------------enigE6BB6D77E9147D3523468B5E-- --===============1019480178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1019480178==-- From ipsec-bounces@ietf.org Fri Oct 1 14:19:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03706 for ; Fri, 1 Oct 2004 14:19:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRY1-0006cu-49; Fri, 01 Oct 2004 13:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRLf-0003NH-NE for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 13:37: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 NAA29052 for ; Fri, 1 Oct 2004 13:37:36 -0400 (EDT) Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CDRUA-00053j-C3 for ipsec@ietf.org; Fri, 01 Oct 2004 13:46:26 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 1 Oct 2004 17:37:37 -0000 Message-ID: <004a01c4a7dd$5ada3f40$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , "Stephen Kent" References: <200409302331.i8UNV5Sj099207@givry.rennes.enst-bretagne.fr> Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) Date: Fri, 1 Oct 2004 10:37:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Steve, I just had one minor comment about the decorrelation part below. > > >=> I have no problem with the decorrelation idea (I began with pattern > >matching and term rewriting systems where the problem is hard, BTW > >IMHO decorrelation is related to completion, i.e., Knuth-Bendix algorithm). > > But I still believe a statement explaining the SPD is considered as > >being decorrelated after the end of 4.4.1 should be fine. > > > > >=> so the SAD check works for the first example but not (yet) for the > > >second where the rule 2 is added* after the creation of the SAD entry > > >for the rule 1 (*: after in time, before in order). > > > > section 4.4.1 concludes with a brief section: > > > > Handling Changes to the SPD while the System is Running > > > > If a change is made to the SPD while the system is running, a check > > SHOULD be made of the effect of this change on extant SAs. An > > implementation MAY choose to check the impact of an SPD change on > > extant SAs and to provide a user/administrator with a mechanism for > > configuring what actions to take, e.g., delete an affected SA, allow > > an affected SA to continue unchanged, etc. > > > > i think this addressed your concern. > > > >=> yes but this conflicts with the end of 4.4.2: > > > > For each of the selectors defined in Section 4.4.1.1, the entry for > > an inbound SA in the SAD MUST contain the value or values negotiated > > at the time the SA was created. For a receiver, these values are used > > to check that the header fields of an inbound packet (after IPsec > > processing) match the selector values negotiated for the SA. For the > > receiver, this is part of verifying that a packet arriving on an SA > > is consistent with the policy for the SA. (See Section 6 for rules > > for ICMP messages.) These fields can have the form of specific > > values, ranges, ANY, or OPAQUE, as described in section 4.4.1.1, > > "Selectors." > > > >(note I like the idea of explaining that the SAD selectors are in fact > >the inbound SPD cache!) > > We will note explicitly that the SAD acts as a cache for selector > checking for inbound traffic on SAs. However, I do not see why you Yes, this would help. Note that at end of section 5 there is already some text For inbound IPsec traffic, the SAD entry selected by the SPI serves as the cache for the selectors to be matched against arriving IPsec packets, after AH or ESP processing has been performed. But still there could be some extra clarification in the section where Decorrelation is defined. It talks about how it is not needed for host implementations where sockets can be used for caching. Perhaps, some text there would help i guess. The other possibility is to also mention that if decorrelation is not done, then SPD should be checked explicitly. This will make it easy and useful for implementers who have not implemented decorrelation (also for folks who are used to RFC 2401 and transitioning to 2401bis). -mohan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 1 14:44:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05788 for ; Fri, 1 Oct 2004 14:44:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDS57-0006aS-AY; Fri, 01 Oct 2004 14:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRp5-0005vz-Iq for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 14:08:03 -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 OAA02584 for ; Fri, 1 Oct 2004 14:08:00 -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 1CDRxZ-0006Ep-Nc for ipsec@ietf.org; Fri, 01 Oct 2004 14:16:51 -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 i91I31d14263 for ; Fri, 1 Oct 2004 14:03:01 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i91I4wg7028593 for ; Fri, 1 Oct 2004 14:04:58 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4DaO13; Fri, 1 Oct 04 14:04:55 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i91I5iJ18051; Fri, 1 Oct 2004 11:05:44 -0700 (PDT) Message-ID: <415D9CE5.7010107@isi.edu> Date: Fri, 01 Oct 2004 11:07:33 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Ipsec] question about 2401bis tunnels and fragments X-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="===============1772249840==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1772249840== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7DAB81909B078C51F1772411" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7DAB81909B078C51F1772411 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The following discusses some of the text regarding fragmentation and tunnel mode. I checked the archives, and although fragmentation issues have been discussed numerous times, I did not find that this particular issue had been covered. If it has, can someone please point me at the thread; if not, I'd like to raise it now (it's a minor editing issue, IMO). ------------------------------ Some of the descriptions on page 13/14 about the need for tunnel mode are indeed needs for tunnels (e.g., reassembly), but not necessarily need tunnel mode, e.g.: > Several concerns motivate the use of tunnel mode for an SA involving > a security gateway. For example, if there are multiple paths (e.g., > via different security gateways) to the same destination behind a > security gateway, it is important that an IPsec packet be sent to the > security gateway with which the SA was negotiated. Similarly, a > packet that might be fragmented en-route must have all the fragments > delivered to the same IPsec instance for reassembly prior to > > > Kent & Seo [Page 14] > > Internet Draft Security Architecture for IP September 2004 > > > cryptographic processing. Also, when a fragment is processed by IPsec > and transmitted, then fragmented en-route, it is critical that there > be inner and outer headers to retain the fragmentation state data for > the pre- and post-IPsec packet formats. Hence there are several > reasons for employing tunnel mode when either end of an SA is a > security gateway. as well as end sec D.1 on page 78: > In 2401bis, we have explicitly said that it is OK to use transport > mode in cases where the IPsec implementation is not the ultimate > destination, e.g., between two SGs. In principle, this creates a new > opportunity for outbound, plaintext fragments to be mapped to a > transport mode SA for IPsec processing. However, in these new > contexts in which a transport mode SA is now approved for use, it > seems likely that we can continue to prohibit transmission of > fragments, as seen by IPsec. For example, in an IP overlay network, > packets being sent over transport mode SAs are IP-in-IP tunneled and > thus have the necessary inner header to accommodate fragmentation > prior to IPsec processing. When carried via a transport mode SA, > IPsec would not examine the inner IP header for such traffic, and > thus would not consider the packet to be a fragment. Thus it seems > reasonable to retain the prohibition on carrying IPv4 fragments on > transport mode SAs, even when the source or destination is an SG. It's not clear how it will help to prohibit IPv4 fragments on such tunnels; the packets that are fragmented are encapsulated in IP headers that do not indicate them as fragments (the outer packet doesn't necessarily have an offset when the inner one does). Joe --------------enig7DAB81909B078C51F1772411 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBXZztE5f5cImnZrsRAqEVAKDYTtTi5NnN3NFioPFoGnCXHAg7BQCglKOG Zy7X8TUiDEUnEfyah7LTmjI= =MUmu -----END PGP SIGNATURE----- --------------enig7DAB81909B078C51F1772411-- --===============1772249840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1772249840==-- From ipsec-bounces@ietf.org Fri Oct 1 17:06:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19056 for ; Fri, 1 Oct 2004 17:06:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTma-0007JS-HZ; Fri, 01 Oct 2004 16:13:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTQa-0002mO-3P for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 15:50:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11071 for ; Fri, 1 Oct 2004 15:50:50 -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 1CDTZ5-0001lW-Vc for ipsec@ietf.org; Fri, 01 Oct 2004 15:59: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 i91Jjod00274 for ; Fri, 1 Oct 2004 15:45:51 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i91Jlj60012714 for ; Fri, 1 Oct 2004 15:47:45 -0400 (EDT) Received: from unknown(132.248.25.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1Zay0y; Fri, 1 Oct 04 15:47:41 -0400 Date: Fri, 01 Oct 2004 14:51:07 -0600 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pybxrgnmgsreosqeelgl" X-Spam-Score: 2.8 (++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 ----------pybxrgnmgsreosqeelgl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >foto3 and MP3


:)

----------pybxrgnmgsreosqeelgl Content-Type: image/bmp; name="mkwaiexahy.bmp" Content-Disposition: attachment; filename="mkwaiexahy.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk3qBwAAAAAAADYAAAAoAAAAOQAAABEAAAABABAAAAAAALQHAAAAAAAAAAAAAAAAAAAAAAAA /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/ /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//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//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//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/ /3+UPyoDKgOUP/9//3//fyoDKgP/f/9//3//f/9/lD8qAyoDlD//f/9//3//f/9/KgMqA/9/ /3/aX5Q/KgMqA7dP/3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3+3TyoDt0+3TyoDt0//f/9/KgMqA9pf/3//f/9/t08qA7dP2l8qA5Q//3//f/9/ /38qAyoD/3//f5Q/KgPaX7dPKgOUP/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f5Q/KgP/f/9/KgOUP/9//3+UPyoD2l//f/9//3+UPyoD/3//fyoD KgP/fyoDKgMqAyoDKgMqA/9//3//f/9//38qAyoD/3//f/9//3//f/9//3//f/9//3//f/9/ AAD/f/9//3//f/9//3//f/9//3//f/9/KgMqA/9//38qAyoD/3//f7dPKgO3T/9//3//fyoD KgP/f/9/KgMqA/9/lD+3T/9/KgMqA/9//3//f/9//3//fyoDKgP/f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//38qAyoD/3//fyoDKgP/f/9/2l8qA5Q/ /3//f/9/KgMqA9pf2l8qA5Q//3/aX5Q//38qAyoD/3//f/9//3//f/9/KgMqA/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/KgMqA/9/ /3//fyoDKgPaX/9//38qAyoDlD8qA5Q//3//f/9/KgPaXyoDKgP/f/9/lD8qA9pft08qA5Q/ /3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/KgMqA/9/ /38qAyoD/3//f/9/t08qA7dP/3//fyoDKgP/f/9//3//f/9//3+3T5Q/KgMqA/9//3+UPyoD KgMqA5Q//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9/ /3+UPyoD/3//fyoDlD//f/9//3//fyoDKgP/f/9/lD8qA/9//3//f/9//3//f/9/KgMqAyoD /3//f7dPKgO3T/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//f7dPKgO3T7dPKgO3T/9//3//f/9/2l8qA5Q//3/aXyoDt0/aXyoDlD//f/9/ /3+3TyoDKgP/f/9/2l8qA5Q//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+UPyoDKgOUP/9//38qAyoDKgMqAyoDKgP/f/9/t08qAyoD KgPaX/9//3//f/9/KgMqA/9//3/aXyoDKgMqAyoDKgP/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//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//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//f/9//38AAA== ----------pybxrgnmgsreosqeelgl Content-Type: text/html; name="New_MP3_Player.zip.htm" Content-Disposition: attachment; filename="New_MP3_Player.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: New_MP3_Player.zip
Virus name: W32/Bagle@MM!pwdzip

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

----------pybxrgnmgsreosqeelgl Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------pybxrgnmgsreosqeelgl-- From ipsec-bounces@ietf.org Fri Oct 1 18:29:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03374 for ; Fri, 1 Oct 2004 18:29:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVYD-000685-Ni; Fri, 01 Oct 2004 18:06:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDU48-000347-B3 for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 16:31: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 QAA13776 for ; Fri, 1 Oct 2004 16:31:42 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDUCe-0004S3-Tb for ipsec@ietf.org; Fri, 01 Oct 2004 16:40:33 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i91KUwjf024002; Fri, 1 Oct 2004 16:30:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200410011607.i91G76Sj002852@givry.rennes.enst-bretagne.fr> References: <200410011607.i91G76Sj002852@givry.rennes.enst-bretagne.fr> Date: Fri, 1 Oct 2004 16:30:17 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Francis, > > However, I do not see why you > feel that the 4.4.2 text conflicts with the text at the end of 4.4.1. > >=> a possible action of the end of 4.4.1 is to update the selectors of >an affected SA, this is forbiden by the MUST of 4.4.2. IMHO the problem >is in the wording, i.e., "contain" should be changed by "be filled by" >or something else catching the idea the selectors are dynamic and >*always* reflect the SPD as a cache does. I see your point. The phrase "the SAD MUST contain the value or values negotiated at the time the SA was created" is the sticking point. We will reword that to reflect the possibility that the SAD entry was updated as a result of an SPD change. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 1 18:50:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04891 for ; Fri, 1 Oct 2004 18:50:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVtL-0000y3-O6; Fri, 01 Oct 2004 18:28:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVSn-0002eK-8w for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 18:01:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29097 for ; Fri, 1 Oct 2004 18:01:14 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDVbK-0007UF-AJ for ipsec@ietf.org; Fri, 01 Oct 2004 18:10: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 i91LuGd22350 for ; Fri, 1 Oct 2004 17:56:16 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i91LwC0K000054 for ; Fri, 1 Oct 2004 17:58:12 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUgaqea; Fri, 1 Oct 04 17:58:10 -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 i91M0ljh028041; Fri, 1 Oct 2004 18:01:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <415D9CE5.7010107@isi.edu> References: <415D9CE5.7010107@isi.edu> Date: Fri, 1 Oct 2004 17:55:53 -0400 To: Joe Touch From: Stephen Kent Subject: Re: [Ipsec] question about 2401bis tunnels and fragments 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: 31247fb3be228bb596db9127becad0bc Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:07 AM -0700 10/1/04, Joe Touch wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enig7DAB81909B078C51F1772411" > >The following discusses some of the text regarding fragmentation and >tunnel mode. I checked the archives, and although fragmentation >issues have been discussed numerous times, I did not find that this >particular issue had been covered. If it has, can someone please >point me at the thread; if not, I'd like to raise it now (it's a >minor editing issue, IMO). > >------------------------------ > >Some of the descriptions on page 13/14 about the need for tunnel >mode are indeed needs for tunnels (e.g., reassembly), but not >necessarily need tunnel mode, e.g.: > >> Several concerns motivate the use of tunnel mode for an SA involving >> a security gateway. For example, if there are multiple paths (e.g., >> via different security gateways) to the same destination behind a >> security gateway, it is important that an IPsec packet be sent to the >> security gateway with which the SA was negotiated. Similarly, a >> packet that might be fragmented en-route must have all the fragments >> delivered to the same IPsec instance for reassembly prior to >> >> >> Kent & Seo [Page 14] >> >> Internet Draft Security Architecture for IP September 2004 >> >> >> cryptographic processing. Also, when a fragment is processed by IPsec >> and transmitted, then fragmented en-route, it is critical that there >> be inner and outer headers to retain the fragmentation state data for >> the pre- and post-IPsec packet formats. Hence there are several >> reasons for employing tunnel mode when either end of an SA is a >> security gateway. > >as well as end sec D.1 on page 78: > >> In 2401bis, we have explicitly said that it is OK to use transport >> mode in cases where the IPsec implementation is not the ultimate >> destination, e.g., between two SGs. In principle, this creates a new >> opportunity for outbound, plaintext fragments to be mapped to a >> transport mode SA for IPsec processing. However, in these new >> contexts in which a transport mode SA is now approved for use, it >> seems likely that we can continue to prohibit transmission of >> fragments, as seen by IPsec. For example, in an IP overlay network, >> packets being sent over transport mode SAs are IP-in-IP tunneled and >> thus have the necessary inner header to accommodate fragmentation >> prior to IPsec processing. When carried via a transport mode SA, >> IPsec would not examine the inner IP header for such traffic, and >> thus would not consider the packet to be a fragment. Thus it seems >> reasonable to retain the prohibition on carrying IPv4 fragments on >> transport mode SAs, even when the source or destination is an SG. > >It's not clear how it will help to prohibit IPv4 fragments on such >tunnels; the packets that are fragmented are encapsulated in IP >headers that do not indicate them as fragments (the outer packet >doesn't necessarily have an offset when the inner one does). > >Joe You seem to be addressing two distinct issues above. The first is that the text on page 13/14 emphasizes the traditional use of tunnel mode in IPsec, and does not address the possible use of IP-in-IP tunnels effected via transport mode. That is correct, but I am reluctant to review the whole document to find and change every place where we discuss tunnel mode, with an eye toward discussing the traditional and the overlay network uses of this mode, and how they may differ. The text in D.1 documents the rationale for the decisions the WG made re fragmentation. Here the concern is that fragments carried via SAs pose problems for the access control checks. But, as the text notes, this is not an issue for a transport mode SA which is using IP-in-IP tunneling, since IPsec does not see the inner IP header in this case. I agree that we should re-write the paragraph you cite to make this clearer. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 1 18:56:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05689 for ; Fri, 1 Oct 2004 18:56:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVtW-00011I-4p; Fri, 01 Oct 2004 18:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVTL-00036Z-Sa for ipsec@megatron.ietf.org; Fri, 01 Oct 2004 18:01:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29154 for ; Fri, 1 Oct 2004 18:01:49 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDVbt-0007UY-42 for ipsec@ietf.org; Fri, 01 Oct 2004 18:10:41 -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 i91M0ljj028041; Fri, 1 Oct 2004 18:01:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <004a01c4a7dd$5ada3f40$861167c0@adithya> References: <200409302331.i8UNV5Sj099207@givry.rennes.enst-bretagne.fr> <004a01c4a7dd$5ada3f40$861167c0@adithya> Date: Fri, 1 Oct 2004 17:59:44 -0400 To: "Mohan Parthasarathy" From: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipsec@ietf.org, Karen Seo , 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 Mohan, > >Yes, this would help. Note that at end of section 5 there is already some text > > For inbound IPsec traffic, the SAD entry selected by the SPI serves > as the cache for the selectors to be matched against arriving IPsec > packets, after AH or ESP processing has been performed. > >But still there could be some extra clarification in the section >where Decorrelation >is defined. It talks about how it is not needed for host implementations where >sockets can be used for caching. Perhaps, some text there would help i guess. > >The other possibility is to also mention that if decorrelation is >not done, then >SPD should be checked explicitly. This will make it easy and useful for >implementers who have not implemented decorrelation (also for folks who >are used to RFC 2401 and transitioning to 2401bis). I am happy to refine the discussion of decorrelation and make the change that Francis noted at the end of 4.4.2. But, we chose to adopt the decorrelation model as the basis for explaining IPsec processing because it simplifies the discussion overall, allowing caching. I do not want to go back and try to accommodate non-decorrelated processing in the model. The exception, which we note and that you cited, is that native host implementations need not decorrelate the SPD because they implicitly perform caching. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 00:22:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29481 for ; Mon, 4 Oct 2004 00:22:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJsu-0001OP-Jd; Sun, 03 Oct 2004 23:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJlx-00063Z-TH for ipsec@megatron.ietf.org; Sun, 03 Oct 2004 23:44: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 XAA14924 for ; Sun, 3 Oct 2004 23:44:20 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEFBQ-0007Pu-5p for ipsec@ietf.org; Sun, 03 Oct 2004 18:50:25 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Sun, 3 Oct 2004 15:40:47 -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, 3 Oct 2004 15:40:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] draft-ietf-ipsec-ikev2-17.txt Date: Sun, 3 Oct 2004 15:40:30 -0700 Message-ID: Thread-Topic: [Ipsec] draft-ietf-ipsec-ikev2-17.txt Thread-Index: AcSpBkN2WFqk3WgJSXWBEZu3eD8jOAAHCmgAAB268yA= From: "Charlie Kaufman" To: "Yoav Nir" X-OriginalArrivalTime: 03 Oct 2004 22:40:28.0303 (UTC) FILETIME=[FB3791F0:01C4A999] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Damn! I can't believe I missed this. I just rescanned the IPsec list and I think this is the only correction I missed, but if anyone else doesn't see their correction on the list below, please let me know. I presumably can fix this one during AUTH48, unless I forget it again. I'm going to put a yellow sticky on my forehead. --Charlie -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Sunday, October 03, 2004 1:26 AM To: Charlie Kaufman Subject: RE: [Ipsec] draft-ietf-ipsec-ikev2-17.txt Did you fix the definition of "Attribute Type" is section 3.15.1? It should be 15 bits rather than 7, just like in the diagram.=20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Charlie Kaufman Sent: Sunday, October 03, 2004 7:03 AM To: ipsec@ietf.org Subject: [Ipsec] draft-ietf-ipsec-ikev2-17.txt One more time, with feeling... A couple more last minute changes. --Charlie H.17 Changes from IKEv2-16 to IKEv2-17 September 2004 1) Removed all references to Alice and Bob, replacing them with "the initiator" and "the responder". Also fixed the corresponding he/she, his/her, and the capitalization of initiator and responder. 2) Changed specification of BER encoded fields to be DER encoded fields. 3) Removed obsolete reference to CA names appearing in CERTREQ fields. 4) Fixed the specification of INTERNAL_IPx_SUBNET Configuration Attributes to indicate that they could be multi-valued. 5) Added informative references to RFC 2402 and RFC 2406. 6) Fixed a formatting glitch in the computation of AUTH. _______________________________________________ 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 Oct 4 00:23:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29548 for ; Mon, 4 Oct 2004 00:23:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDyYW-0002fg-Jx; Sun, 03 Oct 2004 01:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDyWy-0001Z2-H9 for ipsec@megatron.ietf.org; Sun, 03 Oct 2004 01:03: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 BAA01921 for ; Sun, 3 Oct 2004 01:03:32 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDyfl-0004vZ-JU for ipsec@ietf.org; Sun, 03 Oct 2004 01:12:38 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Sat, 2 Oct 2004 22:02:56 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 2 Oct 2004 22:03:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Oct 2004 22:03:04 -0700 Message-ID: Thread-Topic: draft-ietf-ipsec-ikev2-17.txt Thread-Index: AcSpBkN2WFqk3WgJSXWBEZu3eD8jOA== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 03 Oct 2004 05:03:16.0380 (UTC) FILETIME=[4AD83DC0:01C4A906] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] draft-ietf-ipsec-ikev2-17.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable One more time, with feeling... A couple more last minute changes. --Charlie H.17 Changes from IKEv2-16 to IKEv2-17 September 2004 1) Removed all references to Alice and Bob, replacing them with "the initiator" and "the responder". Also fixed the corresponding he/she, his/her, and the capitalization of initiator and responder. 2) Changed specification of BER encoded fields to be DER encoded fields. 3) Removed obsolete reference to CA names appearing in CERTREQ fields. 4) Fixed the specification of INTERNAL_IPx_SUBNET Configuration Attributes to indicate that they could be multi-valued. 5) Added informative references to RFC 2402 and RFC 2406. 6) Fixed a formatting glitch in the computation of AUTH. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 04:28:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11011 for ; Mon, 4 Oct 2004 04:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEO7V-00009M-TL; Mon, 04 Oct 2004 04:22:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEO3n-0007wh-1E for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 04:19: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 EAA10586 for ; Mon, 4 Oct 2004 04:19:04 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEOCp-0005eU-0F for ipsec@ietf.org; Mon, 04 Oct 2004 04:28:27 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i948J1hr027467 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 4 Oct 2004 11:19:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i948J0HH027464; Mon, 4 Oct 2004 11:19:00 +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: <16737.1908.314598.364496@fireball.kivinen.iki.fi> Date: Mon, 4 Oct 2004 11:19:00 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Retry: IANA registry modifications to draft-ietf-ipsec-nat-t-ike X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit [I sent this to the list last week, but I could not see it appearing on the list, so I assume it was stuck in the spam filters as I sent it from the different address. Retrying now with my iki-address, hopefully this will get through]. Message-ID: <16731.58588.849432.183206@ryijy.hel.internal> From: Tero Kivinen To: ipsec@ietf.org CC: tytso@mit.edu, byfraser@cisco.com, cotton@icann.org, smb@research.att.com, housley@vigilsec.com, Ari.Huttunen@F-Secure.com, briansw@microsoft.com, vvolpe@cisco.com Subject: IANA registry modifications to draft-ietf-ipsec-nat-t-ike Date: Thu, 30 Sep 2004 13:50:04 +0300 The draft-ietf-ipsec-nat-t-ike is now in the IANA registry allocation phase, and because of this we needed to allocate new numbers to the NAT-D and NAT-OA payload numbers. During the time the document has been in the various queues the IANA registry for the IKE payload numbers has been created, and numbers 15 and 16 used in the draft has already been given out. Because of this we need to allocate next available numbers, 20 and 21. This will make following changes to the document: Change from section 3.2 the The payload type of the NAT discovery payload is 15. to The payload type of the NAT discovery payload is 20. and change from section 5.2 the The paylaod type for the NAT original address payload is 16. to The payload type for the NAT original address payload is 21. and also probably changing the IANA considerations section 9 from New IKE payload numbers are (There is no IANA registry related to this and no need to create new one, but if one is added these should be added there): NAT-D 15 NAT Discovery Payload NAT-OA 16 NAT Original Address Payload to New IKE payload numbers need to be added to the Next Payload Types registry: NAT-D 20 NAT Discovery Payload NAT-OA 21 NAT Original Address Payload ---------------------------------------------------------------------- There are some other changes to be done during the author 48 hours state, which include: ---------------------------------------------------------------------- Calculating the Vendor-ID, when we know the final RFC number (section 3.1). ---------------------------------------------------------------------- Adding IAB considerations section (requested and agreed during the IESG evaluation): 10. IAB Considerations The UNSAF [RFC 3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC 3715]. and then renumber sections after that accordingly. This also requires adding [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. to the non-normative references section (and change the [Aboba03] to [RFC3715] as it is now out). ---------------------------------------------------------------------- There has also been a request to clarify the section 7 about which packets can be used as an authenticated packet, i.e. change the There are cases where NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover from this, ends which are NOT behind NAT SHOULD use the last valid authenticated packet from the other end to determine which IP and port addresses should be used. To There are cases where NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover from this, ends which are NOT behind NAT SHOULD use the last valid UDP encapsulated IKE or IPsec packet from the other end to determine which IP and port addresses should be used. (i.e change "valid authenticated packet" to "valid UDP encapsulated IKE or IPsec packet"). I myself think that the section would be clear enough with the change, but the changed text might be little clearer. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 12:02:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16248 for ; Mon, 4 Oct 2004 12:02:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEVFZ-0007y6-1W; Mon, 04 Oct 2004 11:59:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEVAK-000765-O9 for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 11:54:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15777 for ; Mon, 4 Oct 2004 11:54:17 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEVJR-0004S8-8e for ipsec@ietf.org; Mon, 04 Oct 2004 12:03:45 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94FsEr7045941 for ; Mon, 4 Oct 2004 08:54:15 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Mon, 4 Oct 2004 08:54:16 -0700 To: IPsec WG From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org It would be great if the reason no one has commented on this is because it is perfect, but that seems unlikely. On the other hand, if this is so uncontroversial (after all, it instantiates what we've been talking about for nearly six years), I'm happy to just take it to the ADs as-is. The document can be found at . The meat of the document is: --------------- 2. Old algorithm requirements RFC 2409 has the following MUST-level and SHOULD-level requirements: o DES for encryption MUST be supported o MD5 and SHA-1 for hashing MUST be supported o Diffie-Hellman MODP group 1 (discrete log 768 bits) MUST be supported o TripleDES for encryption SHOULD be supported o Tiger for hashing SHOULD be supported o DSA and RSA for authentication with signatures SHOULD be supported o RSA for authentication with encryption SHOULD be supported o Diffie-Hellman MODP group 2 (discrete log 1024 bits) SHOULD be supported RFC 2409 gives two conflicting requirement levels for Diffie-Hellman MODP groups with elliptic curves. Section 4 of that specification says "IKE implementations ... MAY support ECP and EC2N groups", but Sections 6.3 and 6.4 say that MODP groups 3 and 4 for EC2N groups SHOULD be supported. 3. New algorithm requirements The new requirements for IKEv1 are: o TripleDES for encryption MUST be supported o SHA-1 for hashing MUST be supported o Diffie-Hellman MODP group 2 (discrete log 1024 bits) MUST be supported o RSA for authentication with signatures SHOULD be supported The other algorithms that were listed at MUST-level and SHOULD-level in RFC 2409 are now MAY-level. This includes DES for encryption, MD5 and Tiger for hashing, Diffie-Hellman MODP group 1, Diffie-Hellman MODP groups with elliptic curves, DSA for authentication with signatures, and RSA for authentication with encryption. Some of these are dropped to MAY due to cryptographic weakness, while others are dropped due to lack of any significant deployment and interoperability. Note that additional algorithms have been developed since the time of RFC 2409 that many people consider SHOULD-level or MUST-level. Most notable among these are discrete log MODP groups with longer key lengths, AES-128 for encryption, and SHA-256 for hashing. They are not included in this document because doing so would cause this document to be an extension to RFC 2409 instead of an update of RFC 2409. --------------- Comments are welcome. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 12:41:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21693 for ; Mon, 4 Oct 2004 12:41:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEVlL-0006Cs-CI; Mon, 04 Oct 2004 12:32:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEVdJ-0004q0-Do for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 12:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19727 for ; Mon, 4 Oct 2004 12:24:14 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEVmQ-0000AO-9M for ipsec@ietf.org; Mon, 04 Oct 2004 12:33:42 -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 i94GNTjf014613; Mon, 4 Oct 2004 12:23:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 4 Oct 2004 12:11:01 -0400 To: "Charlie Kaufman" From: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-ikev2-17.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:03 PM -0700 10/2/04, Charlie Kaufman wrote: >One more time, with feeling... > >A couple more last minute changes. > > --Charlie > >H.17 Changes from IKEv2-16 to IKEv2-17 September 2004 > > 1) Removed all references to Alice and Bob, replacing them with "the > initiator" and "the responder". Also fixed the corresponding he/she, > his/her, and the capitalization of initiator and responder. > > 2) Changed specification of BER encoded fields to be DER encoded > fields. > > 3) Removed obsolete reference to CA names appearing in CERTREQ > fields. > > 4) Fixed the specification of INTERNAL_IPx_SUBNET Configuration > Attributes to indicate that they could be multi-valued. > > 5) Added informative references to RFC 2402 and RFC 2406. Charlie, presumably these are to 2402bis and 2406bis, right? Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 13:13:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24000 for ; Mon, 4 Oct 2004 13:13:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEWE1-00027z-0a; Mon, 04 Oct 2004 13:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEWAD-0001NS-Lv for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 12:58:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23076 for ; Mon, 4 Oct 2004 12:58:14 -0400 (EDT) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEWJI-0006ti-06 for ipsec@ietf.org; Mon, 04 Oct 2004 13:07:43 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.143]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87XZ75Q; Mon, 4 Oct 2004 12:57:43 -0400 Message-Id: <6.1.2.0.2.20041004122258.02dbd5c8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 04 Oct 2004 12:55:30 -0400 To: Stephen Kent , "Mohan Parthasarathy" From: Mark Duffy Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) In-Reply-To: References: <200409302331.i8UNV5Sj099207@givry.rennes.enst-bretagne.fr> <004a01c4a7dd$5ada3f40$861167c0@adithya> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipsec@ietf.org, Karen Seo , 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 Hi Steve, please see comment below... At 05:59 PM 10/1/2004, Stephen Kent wrote: [snip] >>The other possibility is to also mention that if decorrelation is not >>done, then >>SPD should be checked explicitly. This will make it easy and useful for >>implementers who have not implemented decorrelation (also for folks who >>are used to RFC 2401 and transitioning to 2401bis). > >I am happy to refine the discussion of decorrelation and make the change >that Francis noted at the end of 4.4.2. But, we chose to adopt the >decorrelation model as the basis for explaining IPsec processing because >it simplifies the discussion overall, allowing caching. I do not want to >go back and try to accommodate non-decorrelated processing in the model. The above statement about accommodating non-decorrelated processing got me concerned. It is my understanding that the decorrelated SPD is meant mainly as a model for describing the behavior, and possibly as an implementation hint. It is also my understanding that implementations based on an ordered (non-decorrelated) SPD are still to be "accommodated" in the sense that they can fulfill the requirements of the protocol. Can you confirm this? By not "accommodating" the non-decorrelated approach do you mean not describing it in the document, or not caring about whether it can be used as an implementation technique? I hope it is the former. Thanks, Mark > The exception, which we note and that you cited, is that native host > implementations need not decorrelate the SPD because they implicitly > perform caching. > >Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 14:40:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01748 for ; Mon, 4 Oct 2004 14:40:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXee-0002og-Jk; Mon, 04 Oct 2004 14:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXc0-0002By-Vk for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 14:32: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 OAA01084 for ; Mon, 4 Oct 2004 14:31:03 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEXl8-0006rt-M8 for ipsec@ietf.org; Mon, 04 Oct 2004 14:40:32 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 4 Oct 2004 11:30:31 -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, 4 Oct 2004 11:30:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] draft-ietf-ipsec-ikev2-17.txt Date: Mon, 4 Oct 2004 11:30:31 -0700 Message-ID: Thread-Topic: [Ipsec] draft-ietf-ipsec-ikev2-17.txt Thread-Index: AcSqLp4Tl3ry99F9RFaBXObO0F22YAAEPiuw From: "Charlie Kaufman" To: "Stephen Kent" X-OriginalArrivalTime: 04 Oct 2004 18:30:34.0877 (UTC) FILETIME=[3CDA12D0:01C4AA40] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I couldn't find RFC2402bis and RFC2406bis in forms that could be referenced, so no. Are these part of the set that will be advanced together? If so, I assume there is some mechanism to get them to all reference one another as part of the advancement process. Pointers to how to make sure this happens would be appreciated. --Charlie -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Monday, October 04, 2004 9:11 AM To: Charlie Kaufman Cc: ipsec@ietf.org Subject: Re: [Ipsec] draft-ietf-ipsec-ikev2-17.txt At 10:03 PM -0700 10/2/04, Charlie Kaufman wrote: >One more time, with feeling... > >A couple more last minute changes. > > --Charlie > >H.17 Changes from IKEv2-16 to IKEv2-17 September 2004 > > 1) Removed all references to Alice and Bob, replacing them with "the > initiator" and "the responder". Also fixed the corresponding he/she, > his/her, and the capitalization of initiator and responder. > > 2) Changed specification of BER encoded fields to be DER encoded > fields. > > 3) Removed obsolete reference to CA names appearing in CERTREQ > fields. > > 4) Fixed the specification of INTERNAL_IPx_SUBNET Configuration > Attributes to indicate that they could be multi-valued. > > 5) Added informative references to RFC 2402 and RFC 2406. Charlie, presumably these are to 2402bis and 2406bis, right? Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 14:41:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01872 for ; Mon, 4 Oct 2004 14:41:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXef-0002oo-Bv; Mon, 04 Oct 2004 14:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXcL-0002GA-86 for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 14:31: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 OAA01105 for ; Mon, 4 Oct 2004 14:31:24 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEXlU-0006sD-7D for ipsec@ietf.org; Mon, 04 Oct 2004 14:40:52 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i94IFTjh021030; Mon, 4 Oct 2004 14:15:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20041004122258.02dbd5c8@email> References: <200409302331.i8UNV5Sj099207@givry.rennes.enst-bretagne.fr> <004a01c4a7dd$5ada3f40$861167c0@adithya> <6.1.2.0.2.20041004122258.02dbd5c8@email> Date: Mon, 4 Oct 2004 14:09:59 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipsec@ietf.org, Karen Seo , Mohan Parthasarathy , 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 At 12:55 PM -0400 10/4/04, Mark Duffy wrote: >Hi Steve, please see comment below... > >At 05:59 PM 10/1/2004, Stephen Kent wrote: >[snip] >>>The other possibility is to also mention that if decorrelation is >>>not done, then >>>SPD should be checked explicitly. This will make it easy and useful for >>>implementers who have not implemented decorrelation (also for folks who >>>are used to RFC 2401 and transitioning to 2401bis). >> >>I am happy to refine the discussion of decorrelation and make the >>change that Francis noted at the end of 4.4.2. But, we chose to >>adopt the decorrelation model as the basis for explaining IPsec >>processing because it simplifies the discussion overall, allowing >>caching. I do not want to go back and try to accommodate >>non-decorrelated processing in the model. > >The above statement about accommodating non-decorrelated processing >got me concerned. It is my understanding that the decorrelated SPD >is meant mainly as a model for describing the behavior, and possibly >as an implementation hint. It is also my understanding that >implementations based on an ordered (non-decorrelated) SPD are still >to be "accommodated" in the sense that they can fulfill the >requirements of the protocol. > >Can you confirm this? By not "accommodating" the non-decorrelated >approach do you mean not describing it in the document, or not >caring about whether it can be used as an implementation technique? >I hope it is the former. correlated SPDs are in no way prohibited in 2401bis. it's just that we have found it much easier to describe processing based on a decorrelated SPD. in fact, we have cited places where one has to be careful to mimic the behavior of a correlated SPD implementation, if one uses a decorrelated SPD, so I think this says that we are not ruling out correlated SPD implementations. however, the 2401 processing model contained a mix of assumptions, some of which relate to use of a correlated SPD, and others that do not. in this case, the call to search the SPD to find matching entries was always a problematic aspect of the processing description, and so getting rid of it is appropriate, given that we no longer support nested SAs, for example. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 15:00:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03105 for ; Mon, 4 Oct 2004 15:00:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEY17-0006G1-DQ; Mon, 04 Oct 2004 14:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEXyW-0005qi-Hb for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 14:54:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02788 for ; Mon, 4 Oct 2004 14:54:16 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEY7c-0003HL-Ka for ipsec@ietf.org; Mon, 04 Oct 2004 15:03:45 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94IsBvt090106; Mon, 4 Oct 2004 11:54:11 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <3FFBC907DD03A34CA4410C5C745DEB1204A225FE@wnimail.WoodsideNet.Com> References: <3FFBC907DD03A34CA4410C5C745DEB1204A225FE@wnimail.WoodsideNet.Com> Date: Mon, 4 Oct 2004 11:54:14 -0700 To: "Paul Lambert" , "IPsec WG" From: Paul Hoffman / VPNC Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:20 AM -0700 10/4/04, Paul Lambert wrote: > > is because it is perfect, > >A large step forward! It's about time these were changed. > >> 3. New algorithm requirements >> The new requirements for IKEv1 are: >> o TripleDES for encryption MUST be supported > >Shouldn't this be AES-128? Not if we want this as an update of RFC 2409. This is described a few paragraphs later: > > >> Note that additional algorithms have been developed >> since the time of >> RFC 2409 that many people consider SHOULD-level or >> MUST-level. Most >> notable among these are discrete log MODP groups with longer key >> lengths, AES-128 for encryption, and SHA-256 for >> hashing. They are >> not included in this document because doing so would cause this >> document to be an extension to RFC 2409 instead of an >> update of RFC > > 2409. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 15:13:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04907 for ; Mon, 4 Oct 2004 15:13:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEY9P-0004cD-Cl; Mon, 04 Oct 2004 15:05:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEY3q-0006ma-HQ for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 14:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03059 for ; Mon, 4 Oct 2004 14:59:48 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEYCy-0003q0-C2 for ipsec@ietf.org; Mon, 04 Oct 2004 15:09:17 -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 i94IxGjf023974; Mon, 4 Oct 2004 14:59:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 4 Oct 2004 14:53:04 -0400 To: "Charlie Kaufman" From: Stephen Kent Subject: RE: [Ipsec] draft-ietf-ipsec-ikev2-17.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@ietf.org, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:30 AM -0700 10/4/04, Charlie Kaufman wrote: >I couldn't find RFC2402bis and RFC2406bis in forms that could be >referenced, so no. Are these part of the set that will be advanced >together? If so, I assume there is some mechanism to get them to all >reference one another as part of the advancement process. > >Pointers to how to make sure this happens would be appreciated. > > --Charlie Charlie, yes, they cleared WG last call a long time ago, and have been waiting for 2401bis and IKEv2. Russ tells me that they will be progressed together. I'll ask Karen to send you the current references. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 16:02:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10065 for ; Mon, 4 Oct 2004 16:02:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYp2-00017U-GJ; Mon, 04 Oct 2004 15:48:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYfz-0004en-DQ for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 15:39:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07822 for ; Mon, 4 Oct 2004 15:39:13 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CEYp7-0002A7-IL for ipsec@ietf.org; Mon, 04 Oct 2004 15:48:42 -0400 Received: (qmail 14229 invoked by uid 0); 4 Oct 2004 19:39:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.136.55) by woodstock.binhost.com with SMTP; 4 Oct 2004 19:39:07 -0000 Message-Id: <6.1.2.0.2.20041004151832.03754250@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 04 Oct 2004 15:19:46 -0400 To: "Charlie Kaufman" , "Stephen Kent" From: Russ Housley Subject: RE: [Ipsec] draft-ietf-ipsec-ikev2-17.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 hinging one rfc2401bis. If rfc2401bis is finished quickly, then references to AHbis and ESPbis can be used. Russ At 02:30 PM 10/4/2004, Charlie Kaufman wrote: >I couldn't find RFC2402bis and RFC2406bis in forms that could be >referenced, so no. Are these part of the set that will be advanced >together? If so, I assume there is some mechanism to get them to all >reference one another as part of the advancement process. > >Pointers to how to make sure this happens would be appreciated. > > --Charlie > >-----Original Message----- >From: Stephen Kent [mailto:kent@bbn.com] >Sent: Monday, October 04, 2004 9:11 AM >To: Charlie Kaufman >Cc: ipsec@ietf.org >Subject: Re: [Ipsec] draft-ietf-ipsec-ikev2-17.txt > >At 10:03 PM -0700 10/2/04, Charlie Kaufman wrote: > >One more time, with feeling... > > > >A couple more last minute changes. > > > > --Charlie > > > >H.17 Changes from IKEv2-16 to IKEv2-17 September 2004 > > > > 1) Removed all references to Alice and Bob, replacing them with >"the > > initiator" and "the responder". Also fixed the corresponding >he/she, > > his/her, and the capitalization of initiator and responder. > > > > 2) Changed specification of BER encoded fields to be DER encoded > > fields. > > > > 3) Removed obsolete reference to CA names appearing in CERTREQ > > fields. > > > > 4) Fixed the specification of INTERNAL_IPx_SUBNET Configuration > > Attributes to indicate that they could be multi-valued. > > > > 5) Added informative references to RFC 2402 and RFC 2406. > >Charlie, > >presumably these are to 2402bis and 2406bis, right? > >Steve > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 16:44:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18929 for ; Mon, 4 Oct 2004 16:44:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ28-0007OD-Nu; Mon, 04 Oct 2004 16:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYmA-00084L-8i; Mon, 04 Oct 2004 15:45:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08613; Mon, 4 Oct 2004 15:45:36 -0400 (EDT) Message-Id: <200410041945.PAA08613@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Oct 2004 15:45:35 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-ikev2-17.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-17.txt Pages : 109 Date : 2004-10-4 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-17.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-4152627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152627.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Mon Oct 4 16:48:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19875 for ; Mon, 4 Oct 2004 16:48:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ2D-0007Px-21; Mon, 04 Oct 2004 16:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYmK-0008Cd-JN; Mon, 04 Oct 2004 15:45:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08711; Mon, 4 Oct 2004 15:45:46 -0400 (EDT) Message-Id: <200410041945.PAA08711@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Oct 2004 15:45:46 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-esp-v3-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-09.txt Pages : 40 Date : 2004-10-4 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v3-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v3-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-4152633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152633.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Mon Oct 4 17:38:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28518 for ; Mon, 4 Oct 2004 17:38:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEaIu-0001u3-6c; Mon, 04 Oct 2004 17:23:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ6z-0001uq-H4 for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 16:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10628 for ; Mon, 4 Oct 2004 16:07:06 -0400 (EDT) Received: from smtp803.mail.sc5.yahoo.com ([66.163.168.182]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CEZG6-000653-BA for ipsec@ietf.org; Mon, 04 Oct 2004 16:16:36 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 4 Oct 2004 20:07:05 -0000 Message-ID: <006301c4aa4d$b8caf910$861167c0@adithya> From: "Mohan Parthasarathy" To: "Stephen Kent" References: <200409302331.i8UNV5Sj099207@givry.rennes.enst-bretagne.fr><004a01c4a7dd$5ada3f40$861167c0@adithya> Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis) Date: Mon, 4 Oct 2004 13:07:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Karen Seo , Francis Dupont X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > > > >Yes, this would help. Note that at end of section 5 there is already some text > > > > For inbound IPsec traffic, the SAD entry selected by the SPI serves > > as the cache for the selectors to be matched against arriving IPsec > > packets, after AH or ESP processing has been performed. > > > >But still there could be some extra clarification in the section > >where Decorrelation > >is defined. It talks about how it is not needed for host implementations where > >sockets can be used for caching. Perhaps, some text there would help i guess. > > > >The other possibility is to also mention that if decorrelation is > >not done, then > >SPD should be checked explicitly. This will make it easy and useful for > >implementers who have not implemented decorrelation (also for folks who > >are used to RFC 2401 and transitioning to 2401bis). > > I am happy to refine the discussion of decorrelation and make the > change that Francis noted at the end of 4.4.2. But, we chose to adopt > the decorrelation model as the basis for explaining IPsec processing > because it simplifies the discussion overall, allowing caching. I do > not want to go back and try to accommodate non-decorrelated > processing in the model. The exception, which we note and that you > cited, is that native host implementations need not decorrelate the > SPD because they implicitly perform caching. > I am fine with this. It would avoid a lot of questions in the future if we can state explicitly that (in the decorrelation definition) SAs are used for caching the selectors and is the same as referring to the SPD that it is cached from (or some such thing). Thanks mohan > Steve > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 4 17:44:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29422 for ; Mon, 4 Oct 2004 17:44:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEaMt-0008AF-97; Mon, 04 Oct 2004 17:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZsj-0008F7-9I for ipsec@megatron.ietf.org; Mon, 04 Oct 2004 16:56: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 QAA20843 for ; Mon, 4 Oct 2004 16:56:26 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEa1r-00053Q-Hl for ipsec@ietf.org; Mon, 04 Oct 2004 17:05:56 -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 i94Ktqjf000118; Mon, 4 Oct 2004 16:55:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 4 Oct 2004 16:57:16 -0400 To: "Charlie Kaufman" From: Karen Seo Subject: RE: [Ipsec] draft-ietf-ipsec-ikev2-17.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@ietf.org, kseo@bbn.com, housley@vigilsec.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Charlie K., >I'll ask Karen to send you the current references. For 2401bis, I used the following references for AHbis and ESPbis with the understanding that they would be progressed once 2401bis made it through the mill and that the IETF secretariat would fill in the RFC numbers and month (and presumably year if things go into 2005). Kent, S., "IP Authentication Header", RFC ???, ???? 2004 Kent, S., "IP Encapsulating Security Payload (ESP)", RFC ???, ???? 2004. Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 5 04:56:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04270 for ; Tue, 5 Oct 2004 04:56:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEl3P-0001in-1X; Tue, 05 Oct 2004 04: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 1CEl1V-0001Qf-26 for ipsec@megatron.ietf.org; Tue, 05 Oct 2004 04:50:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03919 for ; Tue, 5 Oct 2004 04:50:15 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CElAk-0003oe-Ap for ipsec@ietf.org; Tue, 05 Oct 2004 04:59:51 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i958o9th022716 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Oct 2004 11:50:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i958o6U5022713; Tue, 5 Oct 2004 11:50:06 +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: <16738.24637.920951.642302@fireball.kivinen.iki.fi> Date: Tue, 5 Oct 2004 11:50:05 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Subject: [Ipsec] Fwd: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 21 min X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > Greetings again. We have talked for over five years about getting rid > of 56-bit DES in IKEv1. So, I have (belatedly) written a draft on > doing this at the same time as updating the other algorithm MUSTs and > SHOULDs. This is a personal draft, not a WG item, but it can be > discussed on this list before I turn it into the IESG as a personal > submission. > > Comments are appreciated. The document seems fine. Perhaps add reference to the NIST announcement of documenting the removal of DES or so might be good idea. Also adding "authentication via pre-shareed keys" to both sections 2 and 3 would be good, so all the requirements are there. Now that is the only one that is left out, as it is not changing. I would actually like to make AES a next MUST cipher, and I do not see problem that we refer new documents here. We are still updating RFC2409 aren't we? Anyways, this will update the ciphers used in the IKEv1 SA, but it does not change the ciphers used in the IPsec SAs. If you want to do that too, you need to update the RFC2407 too. RFC2407 current lists mandatory algorithms as AH with MD5, AH with SHA1, ESP with DES and HMAC-MD5, ESP with NULL cipher. The RFC2406 also lists mandatory algorithms for ESP, i.e it lists: DES in CBC mode, HMAC with MD5, HMAC with SHA-1, NULL authentication algorithm and NULL encryption algorithm. And the RFC2402 lists mandatory algorithms for AH, i.e. it lists; HMAC with MD5 and SHA-1. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 5 13:15:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16731 for ; Tue, 5 Oct 2004 13:15:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEsjI-00009z-Hx; Tue, 05 Oct 2004 13:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEsia-00085w-IZ for ipsec@megatron.ietf.org; Tue, 05 Oct 2004 13:03: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 NAA15231 for ; Tue, 5 Oct 2004 13:03:13 -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 1CEsrj-00016X-7p for ipsec@ietf.org; Tue, 05 Oct 2004 13:12:54 -0400 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i95Gvwd08470 for ; Tue, 5 Oct 2004 12:57:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i95H00Gc026644 for ; Tue, 5 Oct 2004 13:00:00 -0400 (EDT) Received: from unknown(132.248.25.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAANZaic0; Tue, 5 Oct 04 12:59:57 -0400 Date: Tue, 05 Oct 2004 12:03:25 -0600 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------qxvuhanppyeorfawquoz" X-Spam-Score: 2.7 (++) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 ----------qxvuhanppyeorfawquoz Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >fotoinfo


:)

----------qxvuhanppyeorfawquoz Content-Type: image/bmp; name="geqqonilok.bmp" Content-Disposition: attachment; filename="geqqonilok.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk1qCQAAAAAAADYAAAAoAAAAPQAAABMAAAABABAAAAAAADQJAAAAAAAAAAAAAAAAAAAAAAAA /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/ /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//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//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//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//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//fwAAAAD/f/9/917vPQAAAABzTv9//3//fwAAAAD/f/9//3//f/deAAAAAAAAc07/f/9/ /3/vPQAAAADvPf9//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//38AAAAA/3//f+89AAD3XnNOAADvPf9//38AAAAA917/f/9/ /3/vPQAA915zTgAA917/f+89AABzTvdeAADvPf9//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/AAAAAAAAAAAAAAAA/3//f/9//3//fwAA AAD/f/9/7z0AAPde/3//f/9//3//f/9//38AAO89/38AAAAA/3//fwAAAAD/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+89c07/fwAA AAD/f/9//3//f/9//38AAAAA/3//f3NOAABzTv9//3//f/9//3//f/9/AAAAAP9/AAAAAP9/ /38AAAAA/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/3Xu89/38AAAAA/3//f/9//3//f/9/AAAAAP9//3/3XgAA7z3/f/9//3//f+89 AADvPQAAAAD/f3NOAAD3XnNOAABzTv9//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//38AAPdeAAAAAP9//3/vPQAA915zTgAA7z3/f/9/ /38AAAAA917/f/9/7z0AAPde914AAAAA/3//fwAAAAAAAAAA917/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/c07vPQAAAAD/f/9/ 7z0AAAAAAADvPf9//3//f/9/c04AAHNO/3//fwAAAAD/f/9/AAAAAP9/7z0AAPde914AAO89 /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/AAAAAAAA/3//f3NOAABzTv9//3//f/9//3//f/9/AAAAAP9//38AAAAA/3//fwAA 7z3/fwAAAAD/f/9/AAAAAP9//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//f3NOAAAAAP9//3/3XgAA7z3/f/9//3//f/9//3//f/de AADvPf9/7z0AAPdec04AAHNO/3/vPQAA9173XgAA7z3/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//fwAAAAD/f/9/914AAAAA AAAAAAAA/38AAAAAAAAAAAAAAAD/f/9/7z0AAAAAc07/f/9/917vPQAAAADvPfde/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//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//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//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//3//f/9//3//f/9//38AAA== ----------qxvuhanppyeorfawquoz Content-Type: text/html; name="Music_MP3.zip.htm" Content-Disposition: attachment; filename="Music_MP3.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: Music_MP3.zip
Virus name: W32/Bagle@MM!pwdzip

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

----------qxvuhanppyeorfawquoz Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------qxvuhanppyeorfawquoz-- From ipsec-bounces@ietf.org Tue Oct 5 14:44:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24300 for ; Tue, 5 Oct 2004 14:44:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEu61-0006X4-60; Tue, 05 Oct 2004 14:31:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtyV-0005Ld-Pw for ipsec@megatron.ietf.org; Tue, 05 Oct 2004 14:23: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 OAA22624 for ; Tue, 5 Oct 2004 14:23:46 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEu7q-0005OD-Cn for ipsec@ietf.org; Tue, 05 Oct 2004 14:33:27 -0400 Received: from [10.20.30.249] (user-2ivfinm.dialup.mindspring.com [165.247.202.246]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95INa6j040516; Tue, 5 Oct 2004 11:23:40 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16738.24637.920951.642302@fireball.kivinen.iki.fi> References: <16738.24637.920951.642302@fireball.kivinen.iki.fi> Date: Tue, 5 Oct 2004 11:14:57 -0700 To: Tero Kivinen From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 2.9 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:50 AM +0300 10/5/04, Tero Kivinen wrote: >The document seems fine. Thanks! > Perhaps add reference to the NIST >announcement of documenting the removal of DES or so might be good >idea. I'm not so hot on this, because we should also then talk about why MD5 is now not as fine as it was a few months ago, and why MODP Group 1 is not as fine, and so on. If we start doing that, what do I say about moving Tiger to "MAY"? Was that because no one implemented it, or because no one implemented it because no one was confident in its crypto properties? Then there's the question about elliptic curves. I'd kinda rather leave the crypto reasoning vague unless others here really think it is needed for the document. > Also adding "authentication via pre-shareed keys" to both >sections 2 and 3 would be good, so all the requirements are there. Now >that is the only one that is left out, as it is not changing. Good point, thanks. >I would actually like to make AES a next MUST cipher, and I do not see >problem that we refer new documents here. We are still updating >RFC2409 aren't we? No, that's extending RFC 2409. AES was not listed (for obvious historical reasons), so this would be a clear extension. We *can* extend RFC 2409, of course, but that would mean something very different for the process, I think. If we extend it, we probably would need to wind in all the extensions that we have created over the past six years. Yuck. >Anyways, this will update the ciphers used in the IKEv1 SA, but it >does not change the ciphers used in the IPsec SAs. If you want to do >that too, you need to update the RFC2407 too. > >RFC2407 current lists mandatory algorithms as AH with MD5, AH with >SHA1, ESP with DES and HMAC-MD5, ESP with NULL cipher. > >The RFC2406 also lists mandatory algorithms for ESP, i.e it lists: DES >in CBC mode, HMAC with MD5, HMAC with SHA-1, NULL authentication >algorithm and NULL encryption algorithm. Of course. I wanted to be sure we were on the right track with this one. Doing the same thing for 2406 and 2407 is trivial if we agree on what we are doing here. >And the RFC2402 lists mandatory algorithms for AH, i.e. it lists; HMAC >with MD5 and SHA-1. But there is no problem with its requirements, is there? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 5 16:34:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08385 for ; Tue, 5 Oct 2004 16:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvkM-0008JZ-D1; Tue, 05 Oct 2004 16:17:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvZW-0000Mq-0G for ipsec@megatron.ietf.org; Tue, 05 Oct 2004 16:06: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 QAA04118 for ; Tue, 5 Oct 2004 16:06:04 -0400 (EDT) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEvis-0004PN-GZ for ipsec@ietf.org; Tue, 05 Oct 2004 16:15:47 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.78]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87X5B4F; Tue, 5 Oct 2004 16:05:35 -0400 Message-Id: <6.1.2.0.2.20041004135422.02dcf6b0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 05 Oct 2004 16:02:40 -0400 To: "Theodore Ts'o" , ipsec@ietf.org, kent@bbn.con.cnri.reston.va.us, kseo@bbn.com From: Mark Duffy Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt In-Reply-To: <20040929021003.GC435@thunk.org> References: <20040929021003.GC435@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:10 PM 9/28/2004, Theodore Ts'o wrote: >Many thanks to Stephen Kent and Karen Seo for submitting the updated >version of the rfc2401bis-03.txt. At this point, we believe that this >document has addressed all pending issues that have been listed in the >Issue Tracker. So therefore, it is appropriate that we start a one >week working group, starting today and terminating on Tuesday, October >2nd. I presume that was supposed to be Tues Oct *5* :-) Thank you Steve and Karen, this is coming together nicely! Nonetheless, here are a bunch of comments... --Mark ------- In sect. 3.1 p. 8: "In this document, the term "inbound" refers to traffic entering an IPsec implementation via the unprotected interface or emitted by the implementation on the unprotected side of the boundary and directed towards the unprotected interface." I believe the next-to-last word there should be protected, not UNprotected. ------- In sect 4.1 p. 13: "A transport mode SA is a security association typically employed between a pair of hosts to provide end-to-end security services. When security is desired between two intermediate systems along a path (vs. end-to-end use of IPsec), transport mode MAY be used between security gateways or between a security gateway and a host. In the latter case, transport mode may be used to support in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00]) over transport mode SAs." The phrase "in the latter case" may have been meant to refer to "when security is desired between two intermediate systems" as distinct from "between a pair of hosts." But, it can easily be read as referring to "between a security gateway and a host" vs. "between security gateways" and thereby stating that transport mode with in-IP tunneling may be used between an SG and a host but not between 2 SGs. Since I don't think that's the intent I propose the following change: s/In the latter case/In the case where transport mode is used between security gateways or between a security gateway and a host/ -------------- In sect. 4.4.1 re selectors (p. 20): "Since the SPD-I is just a part of the SPD, the same rule applies here, i.e., if a packet that is looked up in the SPD-I cannot be matched to an entry there, then the packet MUST be discarded." In this text, it is not clear to me what "the same rule applies here" is referring back to. Perhaps this can be clarified or removed. -------------------- Also in 4.4.1: If I understand correctly, the SPD-S, SPD-I, and SPD-O are just subcategories of the overall SPD and in the ordered SPD these are all interleaved, is that right? If the SPD has been decorrelated the question doesn't really arise but if not decorrelated and working from an ordered SPD, it's not clear that it makes any sense to look in one of these without looking in all of them. Perhaps the text can clarify this. -------------------- In sect 4.4.1.1 (Selectors), Next Layer Protocol: I believe that for IPv4 the next layer protocol in the packet that is evaluated against the SPD is *always* the value in the Protocol field, i.e. there is no concept of skipping over any encapsulations. I think the description here of skipping over extension headers should be clarified that it applies only to IPv6. ------------------- In sect. 4.4.1.1 p 25-26, where it is describing selectors for ICMP type and code it talks about e.g. "The message type is placed in the most significant 8 bits of the 16-bit selector and the code is placed in the least significant 8 bits. ..." There is similar text for the MH selector. I don't think this is relevant for RFC2401bis; this looks like it belongs in IKEv2, and in fact it is (for icmp anyway). This text should be removed, or if it needs to stay for some reason it should state that it is talking about encoding these selectors for IKE. In sect 4.4.1.3 there is other text about setting port selectors. Is this about setting port selectors in IKE? If so I suggest adding a sentence pointing out that that's what the section is about. ---------------- In 4.4.1.1 and 4.4.1.2. Is "Name" a Selector or is it something else? In 4.4.1.1 (p.26) it's listed as one of the selector types but in 4.4.1.2 it is listed as a part of the SPD entry separate from the selector sets. ------------- 4.4.2.1 Data items in the SAD. Should this list include the Bypass DF bit and Bypass DSCP, (copied from the SPD entry)? ----------------- Sect 5 first paragraph: "But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached, and each cached entry will map to exactly one SA, or indicate that matching traffic should be bypassed or discarded, appropriately. (Note: The original SPD entry might result in multiple SAs, e.g., because of PFP.)" As the text here points out, multiple SAs might be created pursuant to one SPD entry. But it seems like a bit of a leap from that to saying that each cached SPD entry maps to one SA. It doesn't even seem correct, unless the "SPD cache" *by definition of the model* contains entries that map to one SA each. If that is the case it should be so stated; otherwise the statement about each cached SPD entry mapping to one SA should be removed. As far as I can see, nothing is gained by requiring the SPD cache to be so fine-grained. ----------------- In sect. 5.1 item 4: " 4. The packet is passed to the outbound forwarding function (operating outside of the IPsec implementation), to select the interface to which the packet will be directed. This function may cause the packet to be passed back across the IPsec boundary, for additional IPsec processing, e.g., in support of nested SAs. If so, there MUST be an entry in SPD-I database that permits inbound bypassing of the packet, otherwise the packet will be discarded." I don't understand why the last 2 sentences are there. Let's look at the case of an overlay network, which I presume is one of the applications that might cause iterated application of IPsec. After once applying IPsec we have, say, an ESP packet. We do a forwarding lookup on the dest address of the ESP packet and that forwarding lookup selects another (or the same) SPD-O/SPD-S, which the packet is then evaluated against. Where and why does the SPD-I bypass rule come into play in such a scenario? Where is the packet "passed back across the IPsec boundary"? I think perhaps there is more to the model you have in mind here then I am picking up from the text. Ditto for the similar statement in the Inbound Processing section. ----------- In sect 5.1.1 2 several cases where packets are dropped are itemized. There are two categories listed for cases where IKE could not negotiate an appropriate SA: " b1. The IPsec system was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange is administratively prohibited from communicating with the initiator." " b2. The IPsec system was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange could not be contacted." These don't seem to cover all the possible reasons the IKE might fail, for example, the case where the local IPsec device could not successfully authenticate itself to the remote one. I think that either more reasons should be added (with appropriate ICMP type and code), or one or both of the above items should be made more general. For example, b1 could be generalized to "... because a suitable SA could not be negotiated with the IPsec peer at the other end." --------------- In sect 5.1.2 at the bottom of p. 46 there are several references to "DS field". I believe these are referring specifically to the DS field in the *outer* IP header. It would be helpful to make that explicit. ----------- In sect 5.2 p. 51 step 3a it discussed creating an audit log entry. It's not clear whether the auditable event would be any processing done under step 3a, or just the multicast case discussed just before the auditing. But, it doesn't seem in either case that it should be an auditable event -- there is no error case or unusual occurrence here, just normal, vanilla processing. ----------- In sect 7.2 (Separate Tunnel Mode SAs for Non-Initial Fragments): "Also, because an SA of this sort will carry ALL non- initial fragments that match a specified Local/Remote address pair and protocol value, users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms available at both peers." I think the point here is that the fragments carried on this SA belong to packets that might have gone on a variety of separate SAs of varying security, if not for the fragmentation. So I think it makes more sense if we s/algorithms available at both peers/algorithms in use for any traffic between both peers/ ------------- In sect. 7.4 (BYPASS/DISCARD traffic) it says "An implementation MUST support stateful fragment checking to accommodate BYPASS traffic for which a non-trivial port range is specified." This seems to mandate that an implementation support the type of stateful fragment checking that is made a MAY in 7.3. I propose that this statement be changed to include the alternative of dropping the non-initial fragments (which should be the normal behavior *anyway* if there is no applicable SPD policy with port selectors of ANY or OPAQUE). So I would change the above-quoted sentence to: "An implementation MAY BYPASS non-initial fragments pursuant to an SPD policy entry with a non-trivial port range if stateful fragment checking is performed to verify the applicable ports for those fragments." ---------- In sect 8.2.1 (propagation of PMTU), it says that once it has "learned" a new PMTU, the IPsec implementation should wait for outbound traffic for the SA and "When such traffic arrives, if the traffic would exceed the updated PMTU value the traffic MUST be discarded and an appropriate ICMP PMTU message sent." I think that is the correct behavior *if* the packet had DF set, but if it does not then the IPsec implementation should either fragment then encrypt or encrypt then fragment, per its configuration. ----------------- Appendix D has not been updated to align with what was eventually decided, and so may lead to confusion. Perhaps it should just be dropped? ------------- Thanks, Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 5 18:16:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17367 for ; Tue, 5 Oct 2004 18:16:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExXD-0006US-2G; Tue, 05 Oct 2004 18:11:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExWP-0005yM-KU for ipsec@megatron.ietf.org; Tue, 05 Oct 2004 18:11:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16681 for ; Tue, 5 Oct 2004 18:10:58 -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 1CExfl-0004gY-Rf for ipsec@ietf.org; Tue, 05 Oct 2004 18:20:42 -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 i95M5sd04382 for ; Tue, 5 Oct 2004 18:05:55 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i95M7s58027830 for ; Tue, 5 Oct 2004 18:07:54 -0400 (EDT) Received: from boreas.isi.edu(128.9.160.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5aaWv2; Tue, 5 Oct 04 18:07:51 -0400 Received: from [192.168.123.143] (lsanca1-ar42-4-61-170-198.lsanca1.dsl-verizon.net [4.61.170.198]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i95M9TJ04557; Tue, 5 Oct 2004 15:09:29 -0700 (PDT) Message-ID: <41631B9D.9030606@isi.edu> Date: Tue, 05 Oct 2004 15:09:33 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [Ipsec] question about 2401bis tunnels and fragments References: <415D9CE5.7010107@isi.edu> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0669304851==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0669304851== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE99C5A0EDBA3F47A2947A1E5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE99C5A0EDBA3F47A2947A1E5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Comments below... Stephen Kent wrote: > At 11:07 AM -0700 10/1/04, Joe Touch wrote: > >> Content-Type: multipart/signed; micalg=pgp-sha1; >> protocol="application/pgp-signature"; >> boundary="------------enig7DAB81909B078C51F1772411" >> >> The following discusses some of the text regarding fragmentation and >> tunnel mode. I checked the archives, and although fragmentation issues >> have been discussed numerous times, I did not find that this >> particular issue had been covered. If it has, can someone please point >> me at the thread; if not, I'd like to raise it now (it's a minor >> editing issue, IMO). >> >> ------------------------------ >> >> Some of the descriptions on page 13/14 about the need for tunnel mode >> are indeed needs for tunnels (e.g., reassembly), but not necessarily >> need tunnel mode, e.g.: >> >>> Several concerns motivate the use of tunnel mode for an SA involving >>> a security gateway. For example, if there are multiple paths (e.g., >>> via different security gateways) to the same destination behind a >>> security gateway, it is important that an IPsec packet be sent to the >>> security gateway with which the SA was negotiated. Similarly, a >>> packet that might be fragmented en-route must have all the fragments >>> delivered to the same IPsec instance for reassembly prior to >>> >>> >>> Kent & Seo [Page 14] >>> >>> Internet Draft Security Architecture for IP September 2004 >>> >>> >>> cryptographic processing. Also, when a fragment is processed by IPsec >>> and transmitted, then fragmented en-route, it is critical that there >>> be inner and outer headers to retain the fragmentation state data for >>> the pre- and post-IPsec packet formats. Hence there are several >>> reasons for employing tunnel mode when either end of an SA is a >>> security gateway. >> >> >> as well as end sec D.1 on page 78: >> >>> In 2401bis, we have explicitly said that it is OK to use transport >>> mode in cases where the IPsec implementation is not the ultimate >>> destination, e.g., between two SGs. In principle, this creates a new >>> opportunity for outbound, plaintext fragments to be mapped to a >>> transport mode SA for IPsec processing. However, in these new >>> contexts in which a transport mode SA is now approved for use, it >>> seems likely that we can continue to prohibit transmission of >>> fragments, as seen by IPsec. For example, in an IP overlay network, >>> packets being sent over transport mode SAs are IP-in-IP tunneled and >>> thus have the necessary inner header to accommodate fragmentation >>> prior to IPsec processing. When carried via a transport mode SA, >>> IPsec would not examine the inner IP header for such traffic, and >>> thus would not consider the packet to be a fragment. Thus it seems >>> reasonable to retain the prohibition on carrying IPv4 fragments on >>> transport mode SAs, even when the source or destination is an SG. >> >> >> It's not clear how it will help to prohibit IPv4 fragments on such >> tunnels; the packets that are fragmented are encapsulated in IP >> headers that do not indicate them as fragments (the outer packet >> doesn't necessarily have an offset when the inner one does). >> >> Joe > > > You seem to be addressing two distinct issues above. > > The first is that the text on page 13/14 emphasizes the traditional use > of tunnel mode in IPsec, and does not address the possible use of > IP-in-IP tunnels effected via transport mode. That is correct, but I am > reluctant to review the whole document to find and change every place > where we discuss tunnel mode, with an eye toward discussing the > traditional and the overlay network uses of this mode, and how they may > differ. It's more specific than that; it has only to do with the relationship between tunneling and fragmentation. I don't think this issue pervades the doc, but rather it ties in with the second item. > The text in D.1 documents the rationale for the decisions the WG made re > fragmentation. Here the concern is that fragments carried via SAs pose > problems for the access control checks. But, as the text notes, this is > not an issue for a transport mode SA which is using IP-in-IP tunneling, > since IPsec does not see the inner IP header in this case. I agree that > we should re-write the paragraph you cite to make this clearer. > > Steve Agreed; the last sentence is the one that appears to be confusing. Joe --------------enigE99C5A0EDBA3F47A2947A1E5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBYxudE5f5cImnZrsRAm6+AKDS9emrGXuYL4aMph2bjn9ja1CREwCg/jUo Xw2hnTE7Mxj6NJbZmfootNg= =VaIi -----END PGP SIGNATURE----- --------------enigE99C5A0EDBA3F47A2947A1E5-- --===============0669304851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0669304851==-- From ipsec-bounces@ietf.org Tue Oct 5 20:38:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01582 for ; Tue, 5 Oct 2004 20:38:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEzmZ-0005Ov-70; Tue, 05 Oct 2004 20:35:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEzlm-0005H2-81 for ipsec@megatron.ietf.org; Tue, 05 Oct 2004 20:35: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 UAA01350 for ; Tue, 5 Oct 2004 20:35:00 -0400 (EDT) Received: from [211.219.171.125] (helo=taonetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEzuz-0001hU-LX for ipsec@ietf.org; Tue, 05 Oct 2004 20:44:44 -0400 Received: from ipinfrasadcat ([10.0.0.225]) by taonetworks.com (8.12.3/8.12.3) with SMTP id i960Yi0J061978 for ; Wed, 6 Oct 2004 09:34:44 +0900 (KST) Message-ID: <003201c4ab3c$4cf1a9b0$e100000a@ipinfrasadcat> From: =?ks_c_5601-1987?B?wMy067n8?= To: Date: Wed, 6 Oct 2004 09:34:49 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ipsec] unsubsribe X-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="===============1777045182==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1777045182== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C4AB87.B9BEA430" This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C4AB87.B9BEA430 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpUYW9OZXR3b3JrcywgSW5jDQpSZXNlYXJjaCBzdGFm ZiBvZiBVSSBUZWFtLCBEYWViZW9tIExlZQ0KKDE1Mi0wNTMpIDdGIDcwNiwgMjEyLTEzIEd1cm8t RG9uZyBHdXJvLUd1LCBTZW91bCAxNTItMDUzLCBLb3JlYQ0KIA0KTW9iaWxlIDogKzgyLTExLTk5 MjAtMDg1NywgT2ZmaWNlIDogKzgyLTItODY1LTA1NTV+Ng0KRmF4IDogKzgyLTItNTU2LTcwOTMs IE1TTiA6IGhvcnNlMzEwM0Brb3JlYS5jb20= ------=_NextPart_000_002F_01C4AB87.B9BEA430 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PFNUUk9ORz51bnN1YnNjcmliZTwv U1RST05HPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCANCnNpemU9Mj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT08QlI+VGFvTmV0d29ya3MsIA0KSW5jPEJSPlJlc2Vh cmNoIHN0YWZmIG9mIFVJIFRlYW0sIERhZWJlb20gTGVlPEJSPigxNTItMDUzKSA3RiA3MDYsIDIx Mi0xMyANCkd1cm8tRG9uZyBHdXJvLUd1LCBTZW91bCAxNTItMDUzLCBLb3JlYTxCUj4mbmJzcDs8 QlI+TW9iaWxlIDogKzgyLTExLTk5MjAtMDg1NywgDQpPZmZpY2UgOiArODItMi04NjUtMDU1NX42 PEJSPkZheCA6ICs4Mi0yLTU1Ni03MDkzLCBNU04gOiA8QSANCmhyZWY9Im1haWx0bzpob3JzZTMx MDNAa29yZWEuY29tIj5ob3JzZTMxMDNAa29yZWEuY29tPC9BPjwvRk9OVD48L0RJVj48L0JPRFk+ PC9IVE1MPg0K ------=_NextPart_000_002F_01C4AB87.B9BEA430-- --===============1777045182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1777045182==-- From ipsec-bounces@ietf.org Tue Oct 5 22:10:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07428 for ; Tue, 5 Oct 2004 22:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF1Dk-0003sa-KS; Tue, 05 Oct 2004 22:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF1DU-0003kx-L1 for ipsec@megatron.ietf.org; Tue, 05 Oct 2004 22:07: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 WAA07273 for ; Tue, 5 Oct 2004 22:07:42 -0400 (EDT) Received: from cse-mail.unl.edu ([129.93.165.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF1Mt-0006wk-Jb for ipsec@ietf.org; Tue, 05 Oct 2004 22:17:28 -0400 Received: from cse.unl.edu (root@cse.unl.edu [129.93.165.2]) by cse-mail.unl.edu (8.13.1/8.12.10) with ESMTP id i9627dMe003529 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 5 Oct 2004 21:07:39 -0500 (CDT) Received: from yongwang (pcp057937pcs.unl.edu [129.93.195.82]) by cse.unl.edu (8.12.10/8.12.10) with ESMTP id i9627d1K028094 for ; Tue, 5 Oct 2004 21:07:39 -0500 (CDT) From: "ywang" To: Subject: [Ipsec] unsubsribe Date: Tue, 5 Oct 2004 21:07:44 -0500 Message-ID: <000501c4ab49$44c59be0$52c35d81@yongwang> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C4AB1F.5BEF93E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Scanned-By: MIMEDefang 2.45 X-Spam-Score: 0.2 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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_0006_01C4AB1F.5BEF93E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C4AB1F.5BEF93E0" ------=_NextPart_001_0007_01C4AB1F.5BEF93E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit unsubscribe ------=_NextPart_001_0007_01C4AB1F.5BEF93E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

u= nsubscribe

------=_NextPart_001_0007_01C4AB1F.5BEF93E0-- ------=_NextPart_000_0006_01C4AB1F.5BEF93E0 Content-Type: text/plain; name="ATT00003.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00003.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0006_01C4AB1F.5BEF93E0 Content-Type: text/plain; name="SpamAssassinReport.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="SpamAssassinReport.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Spam detection software, running on the system "cse-mail.unl.edu", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see postmaster@cse-mail.unl.edu for details. Content preview: unsubscribe = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TaoNetworks, Inc Research staff of UI Team, Daebeom Lee (152-053) 7F 706, 212-13 Guro-Dong Guro-Gu, Seoul 152-053, Korea [...]=20 Content analysis details: (6.1 points, 5.0 required) pts rule name description ---- ---------------------- = -------------------------------------------------- 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers 1.1 HTML_50_60 BODY: Message is 50% to 60% HTML 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_BASE64_NO_NAME RAW: base64 attachment does not have a file = name 1.8 MIME_BASE64_TEXT RAW: Message text disguised using base64 = encoding ------=_NextPart_000_0006_01C4AB1F.5BEF93E0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0006_01C4AB1F.5BEF93E0-- From ipsec-bounces@ietf.org Wed Oct 6 04:37:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01908 for ; Wed, 6 Oct 2004 04:37:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF7CQ-0004yc-8r; Wed, 06 Oct 2004 04:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF74H-0003bp-W9 for ipsec@megatron.ietf.org; Wed, 06 Oct 2004 04:22: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 EAA00870 for ; Wed, 6 Oct 2004 04:22:35 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF7Dj-0008EU-VV for ipsec@ietf.org; Wed, 06 Oct 2004 04:32:24 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i968MXce004888 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 6 Oct 2004 11:22:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i968MWa0004885; Wed, 6 Oct 2004 11:22:32 +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: <16739.43847.865201.27545@fireball.kivinen.iki.fi> Date: Wed, 6 Oct 2004 11:22:31 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt In-Reply-To: References: <16738.24637.920951.642302@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 28 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > I'm not so hot on this, because we should also then talk about why > MD5 is now not as fine as it was a few months ago, and why MODP Group > 1 is not as fine, and so on. If we start doing that, what do I say > about moving Tiger to "MAY"? Was that because no one implemented it, > or because no one implemented it because no one was confident in its > crypto properties? Then there's the question about elliptic curves. You can use pointers for those others also. > I'd kinda rather leave the crypto reasoning vague unless others here > really think it is needed for the document. Yes, but you can provide pointers for those discussions. I.e. for cipher change point to the NIST, for MODP groups point to the BCP86 / RFC3766 and perhaps also to the RFC2409, which said that group 1 was only for single DES. For Tiger and Elliptic curves, it is quite easy to say that they haven't been used or even tested really, so no point of those being SHOULD. > >I would actually like to make AES a next MUST cipher, and I do not see > >problem that we refer new documents here. We are still updating > >RFC2409 aren't we? > > No, that's extending RFC 2409. AES was not listed (for obvious > historical reasons), so this would be a clear extension. > > We *can* extend RFC 2409, of course, but that would mean something > very different for the process, I think. If we extend it, we probably > would need to wind in all the extensions that we have created over > the past six years. Yuck. I do not think we need to take any other changes than what is required, and we can refer those extensions (AES) by just refering the rfc defining them. I still think that it would be "Update" to the RFC2409 if we simply say that AES (RFC3602) is now MUST to implement cipher. > Of course. I wanted to be sure we were on the right track with this > one. Doing the same thing for 2406 and 2407 is trivial if we agree on > what we are doing here. Good. I just wanted to point it out for other people, as most of the people do not really care what we us in the IKE, everybody is much more interested in the IPsec algorithms. > >And the RFC2402 lists mandatory algorithms for AH, i.e. it lists; HMAC > >with MD5 and SHA-1. > But there is no problem with its requirements, is there? Probably not. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 6 07:33:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13748 for ; Wed, 6 Oct 2004 07:33:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF9v3-0003N5-DP; Wed, 06 Oct 2004 07:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF9t1-000393-Ln for ipsec@megatron.ietf.org; Wed, 06 Oct 2004 07:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13009 for ; Wed, 6 Oct 2004 07:23:10 -0400 (EDT) Received: from ms07.mse2.exchange.ms ([69.25.50.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFA2V-00028K-PU for ipsec@ietf.org; Wed, 06 Oct 2004 07:33:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Oct 2004 07:22:43 -0400 Message-ID: <85CE4E3FD2EC2C4E8AAE39916AC1A383CE08E4@ms07.mse2.exchange.ms> Thread-Topic: unsubsribe Thread-Index: AcSrSg794Dbd8cCkQ9KdCF/Ob8DWwgATKSmQ From: "Bilotti, Matt" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Ipsec] unsubsribe X-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="===============1866825798==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1866825798== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AB96.E66E697A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AB96.E66E697A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable unsubscribe =20 =20 Matthew Bilotti - Chantry Networks Inc. - mbilotti@chantrynetworks.com=20 =20 ------_=_NextPart_001_01C4AB96.E66E697A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

unsubscribe

 

 

Matthew Bilotti - Chantry Networks = Inc. - mbilotti@chantrynetworks.com=  

 

------_=_NextPart_001_01C4AB96.E66E697A-- --===============1866825798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1866825798==-- From ipsec-bounces@ietf.org Wed Oct 6 13:22:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14632 for ; Wed, 6 Oct 2004 13:22:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFFQW-0006xw-VS; Wed, 06 Oct 2004 13:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFFOJ-0006qC-3M for ipsec@megatron.ietf.org; Wed, 06 Oct 2004 13:15:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14026 for ; Wed, 6 Oct 2004 13:15:47 -0400 (EDT) Received: from web13922.mail.yahoo.com ([66.163.176.47]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFFXp-00006L-Fk for ipsec@ietf.org; Wed, 06 Oct 2004 13:25:42 -0400 Message-ID: <20041006171548.46954.qmail@web13922.mail.yahoo.com> Received: from [202.88.181.56] by web13922.mail.yahoo.com via HTTP; Wed, 06 Oct 2004 10:15:48 PDT Date: Wed, 6 Oct 2004 10:15:48 -0700 (PDT) From: Akshat Jain To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ipsec] help required X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 friends I am a relatively new member of this grp. I am interested in security n want to explore more aspects of it related to IP. Can anyone help me out as how to start about it. Also any good site/book/papers that can help me with the basic understanding of the subject. And finally what is new in this field.? Waiting for the replies. Akshat __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 6 13:37:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15681 for ; Wed, 6 Oct 2004 13:37:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFFgg-0001AH-Fh; Wed, 06 Oct 2004 13:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFFeI-0000oR-O8 for ipsec@megatron.ietf.org; Wed, 06 Oct 2004 13:32:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15407 for ; Wed, 6 Oct 2004 13:32:19 -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 1CFFnp-0000vZ-NY for ipsec@ietf.org; Wed, 06 Oct 2004 13:42:14 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i96HRDd20709 for ; Wed, 6 Oct 2004 13:27:14 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i96HTHKN001288 for ; Wed, 6 Oct 2004 13:29:17 -0400 (EDT) Received: from unknown(132.248.25.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAAclaaFc; Wed, 6 Oct 04 13:29:13 -0400 Date: Wed, 06 Oct 2004 12:32:38 -0600 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------aagawsjxnlfyqnhpcoeg" X-Spam-Score: 2.7 (++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 ----------aagawsjxnlfyqnhpcoeg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Animals

:)

----------aagawsjxnlfyqnhpcoeg Content-Type: image/bmp; name="nsvrljqdmd.bmp" Content-Disposition: attachment; filename="nsvrljqdmd.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk02CAAAAAAAADYAAAAoAAAAPwAAABAAAAABABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAA /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/ /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9/QGVAZUBl QGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBlQGVAZUBl QGVAZUBlQGVAZf9//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//3//f/9//3//f/9/ /3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/j3JAZUBlj3L/f/9/QGVAZUBl QGVAZUBl/39AZUBlQGVAZUBlQGX/f1d7j3JAZUBl83b/f/9/QGVAZUBlQGVAZUBl/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/ j3JAZfN2V3tAZY9y/3+PckBl83b/f/9//3//f49yQGXzdv9//3//f/9/j3JAZVd783ZAZfN2 /3+PckBl83b/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//39AZUBl/3//f0BlQGX/f1d7QGVAZVd7/3//f/9/V3tAZUBl V3v/f/9//3//f/9//3//f0BlQGX/f1d7QGVAZVd7/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//f0BlQGX/f/9/QGVAZf9/ /3/zdkBlQGX/f/9//3//f/N2QGVAZf9//3//f/9//3//f/9/QGVAZf9//3/zdkBlQGX/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/83ZAZVd783ZAZfN2/3//f/9/j3JAZY9y/3//f/9//3+PckBlj3L/f/9//3//f/9/ 83ZAZY9y/3//f/9/j3JAZY9y/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//f0BlQGVAZUBlV3v/f/9//3//f0BlQGXzdv9/ /3//f/9/QGVAZfN2/3//f/9/QGVAZUBl/3//f/9//3//f0BlQGXzdv9//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//f49yQGVXe1d7 QGWPcv9//3//f/9/V3tAZUBl/3//f/9//39Xe0BlQGX/f/9//3//f/N2QGWPcv9//3//f/9/ V3tAZUBl/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/QGVAZf9//39AZUBl/3//f/9//3//f0BlQGX/f/9//3//f/9/QGVAZf9/ /3//f/9//39AZUBl/3//f/9//3//f0BlQGX/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+PckBlV3tXe0Blj3L/f0BlQGVXe1d7 QGWPcv9/QGVAZVd7V3tAZY9y/3+PckBlV3tXe0Blj3L/f0BlQGVXe1d7QGWPcv9//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//f1d7 j3JAZUBlj3JXe/9/V3uPckBlQGWPcv9//39Xe49yQGVAZY9y/3//f1d7j3JAZUBlj3L/f/9/ V3uPckBlQGWPcv9//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//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//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//3//f/9//3//f/9//3//f/9/AAA= ----------aagawsjxnlfyqnhpcoeg Content-Type: text/html; name="Cat.zip.htm" Content-Disposition: attachment; filename="Cat.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: Cat.zip
Virus name: W32/Bagle@MM!pwdzip

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

----------aagawsjxnlfyqnhpcoeg Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------aagawsjxnlfyqnhpcoeg-- From ipsec-bounces@ietf.org Wed Oct 6 16:28:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05944 for ; Wed, 6 Oct 2004 16:28:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHlq-000768-FY; Wed, 06 Oct 2004 15:48:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHdc-0003Mc-V1; Wed, 06 Oct 2004 15:39:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27339; Wed, 6 Oct 2004 15:39:46 -0400 (EDT) Message-Id: <200410061939.PAA27339@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 06 Oct 2004 15:39:46 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-rfc2402bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-08.txt Pages : 34 Date : 2004-10-6 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-rfc2402bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-6152736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-6152736.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Thu Oct 7 11:57:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29095 for ; Thu, 7 Oct 2004 11:57:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaOE-0004Ow-4N; Thu, 07 Oct 2004 11:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaEz-00023Q-1R for ipsec@megatron.ietf.org; Thu, 07 Oct 2004 11:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27116 for ; Thu, 7 Oct 2004 11:31:34 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFaOh-0004B2-0I for ipsec@ietf.org; Thu, 07 Oct 2004 11:41:40 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i97FVPPr022600 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 7 Oct 2004 18:31:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i97FVOCa022597; Thu, 7 Oct 2004 18:31:24 +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: <16741.24908.236436.231881@fireball.kivinen.iki.fi> Date: Thu, 7 Oct 2004 18:31:24 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Question about N(COOKIE) and N(INVALID_KE_PAYLOAD) combination X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Lets verify that I have understand this correctly: (HDR(I,R,M) = Header with SPI-I = I, SPI-R = R, and Message-ID = M) Initiator Responder --------- --------- 1. HDR(A,0,0), SAi1, KEi, Ni -> 2. <-- HDR(A,0,0), N(COOKIE) 3. HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni -> 4. <-- HDR(A,0,0), N(COOKIE'), N(INVALID_KE_PAYLOAD) 5. HDR(A,0,0), N(COOKIE'), SAi1, KEi', Ni -> 6. <-- HDR(A,B,0), SAr1, KEr, Nr, [CERTREQ] Now, I have some questions: 1) Are all packets above (1-6) have message id of 0 (I assume yes). 2) Are all packets above (1-6) having exchange type of IKE_SA_INIT (I assume yes). 3) If the responder allows storing state in the step 4, he could also reply without the cookie, and in that case the packet 5, wouldn't have the cookie either. Would the SPI-R still be zero? (I assume no, and I also assume that then packet 5 and 6 would also require same SPI-R, than what was returned in packet 4). I.e. is the responder SPI-R allocated after state is created or only after it is replying with the SAr1. As the responder will use the SPI-R as a reference point to the SA, I assume it needs to allocate it immediately when it stores state. 4) If responder do not include N(COOKIE') in the packet 4, I assume that inititator MUST NOT include N(COOKIE) in its packet 5, i.e. it can only include the cookie if it was sent in the last packet from the other end to it. Btw, with the suggested algorithm in the draft the N(COOKIE) and N(COOKIE') would be same, unless the shared secret was changed in the between. In all cases I assume that the initiator must only send N(COOKIE) out if it just received one in from the responder. 5) if NAT-T was enabled, all the packets above would be using port 500, and only the first IKE_AUTH packet would be using port 4500, and the first responder packet having the N(NAT_DETECTION_*_IP) payloads would be packet 6, and all initiator packets above would include them. Ps. Page 60 of draft-ietf-ipsec-ikev2-17.txt have one reference to the IKE_INIT_SA instead of IKE_SA_INIT. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 7 14:37:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09893 for ; Thu, 7 Oct 2004 14:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFc4b-0006ZS-IN; Thu, 07 Oct 2004 13:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFc2N-0005ow-QN for ipsec@megatron.ietf.org; Thu, 07 Oct 2004 13:26:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06684 for ; Thu, 7 Oct 2004 13:26:40 -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 1CFcBx-0003A2-L7 for ipsec@ietf.org; Thu, 07 Oct 2004 13:36:48 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i97HLOd03844 for ; Thu, 7 Oct 2004 13:21:24 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i97HNRgO019908 for ; Thu, 7 Oct 2004 13:23:27 -0400 (EDT) Received: from unknown(132.248.25.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhZaq4M; Thu, 7 Oct 04 13:23:24 -0400 Date: Thu, 07 Oct 2004 12:26:53 -0600 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yrgjiwarliefpkrxcbwq" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------yrgjiwarliefpkrxcbwq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >The snake


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

----------yrgjiwarliefpkrxcbwq Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------yrgjiwarliefpkrxcbwq-- From ipsec-bounces@ietf.org Thu Oct 7 22:30:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28123 for ; Thu, 7 Oct 2004 22:30:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFkTH-0002Dp-CO; Thu, 07 Oct 2004 22:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFkOS-0001KS-2N for ipsec@megatron.ietf.org; Thu, 07 Oct 2004 22:22:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27539 for ; Thu, 7 Oct 2004 22:22:01 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFkY6-0007xj-Q2 for ipsec@ietf.org; Thu, 07 Oct 2004 22:32:13 -0400 Received: from SriniSony (dhcp-71.intoto.com [10.1.5.71]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i982LsRP008157; Thu, 7 Oct 2004 19:21:55 -0700 Message-ID: <145001c4acdd$8fffc370$1411a8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: "Tero Kivinen" , References: <16741.24908.236436.231881@fireball.kivinen.iki.fi> Subject: Re: [Ipsec] Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)combination Date: Thu, 7 Oct 2004 19:21:43 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, This is what I think would need to happen. Initiator Responder 1. HDR(A,0,0), SAi1, KEi, Ni--> <--- HDR(A,0,0)N(COOKIE) 2. HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni-----> <---- HDR(A,B,0) N(INVALID_KE_PAYLOAD) (At this time, state is created by both responder too.) 3. HDR(A,B,1), SAi1, KEi(new), Ni-------> <----- HDR(A,B,1), SAr1, KEr, Nr. [CERTREQ] I feel that Initiator need to choose message id 1 in transaction 3. if transaction 3 uses message ID 0, it is possible that responder might return the previous response as message id is same. If the responder chooses not to create the state in transaction 2, it would be treating message ID 0 as new transaction and that would work. Since, initiator would not know the behaviour of the responder, it is better if Initiator chooses new message ID for transaction 3. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "Tero Kivinen" To: Sent: Thursday, October 07, 2004 8:31 AM Subject: [Ipsec] Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)combination > > Lets verify that I have understand this correctly: > > (HDR(I,R,M) = Header with SPI-I = I, SPI-R = R, and Message-ID = M) > > Initiator Responder > --------- --------- > 1. HDR(A,0,0), SAi1, KEi, Ni -> > send cookie> > > 2. <-- HDR(A,0,0), N(COOKIE) > > > > 3. HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni -> > > cookie, but notices that KEi > is not proper group, and > wants to change it, it still > does not want to store state, > so it sends another > N(COOKIE), might be same than > last time> > > 4. <-- HDR(A,0,0), N(COOKIE'), > N(INVALID_KE_PAYLOAD) > > and with proper KE payload> > > 5. HDR(A,0,0), N(COOKIE'), SAi1, > KEi', Ni -> > > own packet> > > 6. <-- HDR(A,B,0), SAr1, KEr, Nr, > [CERTREQ] > > > > Now, I have some questions: > > 1) Are all packets above (1-6) have message id of 0 (I assume yes). > > 2) Are all packets above (1-6) having exchange type of IKE_SA_INIT (I > assume yes). > > 3) If the responder allows storing state in the step 4, he could also > reply without the cookie, and in that case the packet 5, wouldn't > have the cookie either. Would the SPI-R still be zero? (I assume > no, and I also assume that then packet 5 and 6 would also require > same SPI-R, than what was returned in packet 4). > > I.e. is the responder SPI-R allocated after state is created > or only after it is replying with the SAr1. As the responder > will use the SPI-R as a reference point to the SA, I assume it > needs to allocate it immediately when it stores state. > > 4) If responder do not include N(COOKIE') in the packet 4, I assume > that inititator MUST NOT include N(COOKIE) in its packet 5, i.e. it > can only include the cookie if it was sent in the last packet from > the other end to it. > > Btw, with the suggested algorithm in the draft the N(COOKIE) > and N(COOKIE') would be same, unless the shared secret was > changed in the between. In all cases I assume that the > initiator must only send N(COOKIE) out if it just received one > in from the responder. > > 5) if NAT-T was enabled, all the packets above would be using port > 500, and only the first IKE_AUTH packet would be using port 4500, > and the first responder packet having the N(NAT_DETECTION_*_IP) > payloads would be packet 6, and all initiator packets above would > include them. > > Ps. Page 60 of draft-ietf-ipsec-ikev2-17.txt have one reference to the > IKE_INIT_SA instead of IKE_SA_INIT. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 8 00:22:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05064 for ; Fri, 8 Oct 2004 00:22:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFmCd-00087x-VC; Fri, 08 Oct 2004 00:17:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFm8Z-0006ex-Fc for ipsec@megatron.ietf.org; Fri, 08 Oct 2004 00:13: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 AAA04413 for ; Fri, 8 Oct 2004 00:13:43 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFmIO-0005BX-TJ for ipsec@ietf.org; Fri, 08 Oct 2004 00:23:57 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i984D5I19492; Fri, 8 Oct 2004 00:13:05 -0400 (EDT) Received: from [47.102.178.15] (archt0za.us.nortel.com [47.102.178.15]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S8Z9MNCV; Fri, 8 Oct 2004 00:13:03 -0400 Message-ID: <416613CD.7040806@nortelnetworks.com> Date: Fri, 08 Oct 2004 00:13:01 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)combina tion References: <16741.24908.236436.231881@fireball.kivinen.iki.fi> In-Reply-To: <16741.24908.236436.231881@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Wouldn't this work? HDR(A,0,0), SAi1, KEi, Ni -> <-- HDR(A,0,0), N(COOKIE) HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni -> <-- HDR(A,0,0), N(INVALID_KE_PAYLOAD) The responder could be still stateless (although it does not need to be) to keep things simple! HDR(A,0,0), N(COOKIE), SAi1, KEi', Ni -> <-- HDR(A,B,0), SAr1, KEr, Nr, [CERTREQ] I think mess-ID MUST be zero and exch_type = IKE_SA_INIT. (Sec 2.2. The IKE_SA initial setup messages will always be numbered 0 and 1) If an implementation chooses to include KEi in "cookie" computation, the initiator would have to start all over, i.e., without N(COOKIE). Starting all over might not be such a bad idea, because we can't assume that an implementation won't do that. cheers, Lakshminath Tero Kivinen wrote: > > Lets verify that I have understand this correctly: > > (HDR(I,R,M) = Header with SPI-I = I, SPI-R = R, and Message-ID = M) > > Initiator Responder > --------- --------- > 1. HDR(A,0,0), SAi1, KEi, Ni -> > send cookie> > > 2. <-- HDR(A,0,0), N(COOKIE) > > > > 3. HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni -> > > cookie, but notices that KEi > is not proper group, and > wants to change it, it still > does not want to store state, > so it sends another > N(COOKIE), might be same than > last time> > > 4. <-- HDR(A,0,0), N(COOKIE'), > N(INVALID_KE_PAYLOAD) > > and with proper KE payload> > > 5. HDR(A,0,0), N(COOKIE'), SAi1, > KEi', Ni -> > > own packet> > > 6. <-- HDR(A,B,0), SAr1, KEr, Nr, > [CERTREQ] > > > > Now, I have some questions: > > 1) Are all packets above (1-6) have message id of 0 (I assume yes). > > 2) Are all packets above (1-6) having exchange type of IKE_SA_INIT (I > assume yes). > > 3) If the responder allows storing state in the step 4, he could also > reply without the cookie, and in that case the packet 5, wouldn't > have the cookie either. Would the SPI-R still be zero? (I assume > no, and I also assume that then packet 5 and 6 would also require > same SPI-R, than what was returned in packet 4). > > I.e. is the responder SPI-R allocated after state is created > or only after it is replying with the SAr1. As the responder > will use the SPI-R as a reference point to the SA, I assume it > needs to allocate it immediately when it stores state. > > 4) If responder do not include N(COOKIE') in the packet 4, I assume > that inititator MUST NOT include N(COOKIE) in its packet 5, i.e. it > can only include the cookie if it was sent in the last packet from > the other end to it. > > Btw, with the suggested algorithm in the draft the N(COOKIE) > and N(COOKIE') would be same, unless the shared secret was > changed in the between. In all cases I assume that the > initiator must only send N(COOKIE) out if it just received one > in from the responder. > > 5) if NAT-T was enabled, all the packets above would be using port > 500, and only the first IKE_AUTH packet would be using port 4500, > and the first responder packet having the N(NAT_DETECTION_*_IP) > payloads would be packet 6, and all initiator packets above would > include them. > > Ps. Page 60 of draft-ietf-ipsec-ikev2-17.txt have one reference to the > IKE_INIT_SA instead of IKE_SA_INIT. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 8 06:49:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12920 for ; Fri, 8 Oct 2004 06:49:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFs7O-0008HP-S8; Fri, 08 Oct 2004 06:36:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFs76-0008AD-3G for ipsec@megatron.ietf.org; Fri, 08 Oct 2004 06:36:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12000 for ; Fri, 8 Oct 2004 06:36:38 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsGz-0003QA-7C for ipsec@ietf.org; Fri, 08 Oct 2004 06:46:54 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i98AaWbU003973 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Oct 2004 13:36:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i98AaUxu003970; Fri, 8 Oct 2004 13:36:30 +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: <16742.28077.940436.338326@fireball.kivinen.iki.fi> Date: Fri, 8 Oct 2004 13:36:29 +0300 From: Tero Kivinen To: "Srinivasa Rao Addepalli" Subject: Re: [Ipsec] Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)combination In-Reply-To: <145001c4acdd$8fffc370$1411a8c0@SriniSony> References: <16741.24908.236436.231881@fireball.kivinen.iki.fi> <145001c4acdd$8fffc370$1411a8c0@SriniSony> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 65 min X-Total-Time: 72 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Srinivasa Rao Addepalli writes: > Initiator Responder > 1. HDR(A,0,0), SAi1, KEi, Ni--> > <--- HDR(A,0,0)N(COOKIE) > 2. HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni-----> > <---- HDR(A,B,0) N(INVALID_KE_PAYLOAD) > (At this time, state is created by both responder too.) > 3. HDR(A,B,1), SAi1, KEi(new), Ni-------> > <----- HDR(A,B,1), SAr1, KEr, Nr. [CERTREQ] > > I feel that Initiator need to choose message id 1 in transaction 3. But the setion 2.2 says that IKE_SA initial setup message will always be number 0 and 1, and in your case the IKE_AUTH coming after the 3rd transaction would have message id 2.... > if transaction 3 uses message ID 0, it is possible that responder > might return the previous response as message id is same. Yes, that happens unless, it understand this case separately. > If the responder chooses not to create the state in transaction 2, > it would be treating message ID 0 as new transaction and that would > work. In that case it would need to send new N(COOKIE) too, as in my example. Otherwise it would not know that this is node that has talked to him before. > Since, initiator would not know the behaviour of the responder, it > is better if Initiator chooses new message ID for transaction 3. If the responder allocated SPI-R (B) then it means that it has created state, and if the responder is still using SPI-R of 0, as in N(COOKIE) exchange, then it knows that the other end has not created any state yet. One (not so good) option would also be that in the INVALID_KE_PAYLOAD case the initiator MUST select new SPI-I, i.e. instead of A it would use A', i.e. start new negotiation, and the responder will simply consider the N(INVALID_KE_PAYLOAD) as an error, and refuse to process any further messages to the SA. I.e. the normal INVALID_KE_PAYLOAD exchance without cookies would go: 1. HDR(A,0,0) SAi1, KEi, Ni ---> <--- HDR(A,X,0) N(INVALID_KE_PAYLOAD) 2. HDR(A',0,0) SAi1, KEi(new), Ni ---> <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ] and combined with cookies it would be: 1. HDR(A,0,0) SAi1, KEi, Ni ---> <--- HDR(A,0,0) N(COOKIE) 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> <--- HDR(A,X,0) N(INVALID_KE_PAYLOAD) 3. HDR(A',0,0) SAi1, KEi(new), Ni ---> <--- HDR(A',0,0) N(COOKIE2) 4. HDR(A',0,0) N(COOKIE2), SAi1, KEi(new), Ni ---> <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ] Note, that we need second cookie exchange, as the SPI-I has changed, thus the cookie given in the first step does not work for the A'. Note, that I used SPI-R of X in the N(INVALID_KE_PAYLOAD) error, as I do not know if we need to use 0 or allocate something there. The first packets before SPI-R is allocated by the responder and before the initiator also starts using that, must use different retransmission and window rules anyways. I.e. we must check if the SPI-R is 0, and if so we must use the whole packet to detect retranmissions. So our retranmission policy needs to be so that if the packet is exactly same than previous time, we can retransmit our old packet back. If it is changed then we need to process it again (it might be new negotiation from some one else simply using the same SPI-I than the previous user). The responder could optimize things a little bit, by processing the SAi1 already in the first step, i.e. 1. HDR(A,0,0) SAi1, KEi, Ni ---> <--- HDR(A,0,0) N(COOKIE), N(INVALID_KE_PAYLOAD) 2. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> <--- HDR(A,B,0) SAr1, KEr, Nr, [CERTREQ] but this would open the responder to the DoS attacks as it now needs to do something more complicated than only request cookie for the first packet. Actually the whole error handling in the first packet is not really defined well. The 2.21 does not mention anything about that. I would say the best option is that if anything goes wrong when processing the first IKE_SA_INIT packet from initiator, we simply return packet with zero SPI-R cookie, and containing the error notification(s), and then responder simply deletes all information about the actual exchange. It can use global retransmission system retransmitting exactly same reply back if it receives exactly same request, but nothing more. If the message is different than previous one, we must always process it, just like any new message. Initiator should keep the SPI-I same all the time as otherwise the N(COOKIE) payloads do not match. Also the exchange fails only after it times out, not because of unauthenticated notifications. I.e: 1. HDR(A,0,0) SAi1, KEi, Ni ---> (lost) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) 2. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) (initiator decides to ignore the error message as it is unprotected) 3. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) 4. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) 5. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) 6. Initiator gives up, as the other end does not reply. or 1. HDR(A,0,0) SAi1, KEi, Ni ---> (bit error, or attacker modifying the packet in transit causing invalid syntax) <--- HDR(A,0,0) N(INVALID_SYNTAX) 2. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) <--- HDR(A,0,0) SAr1, KEr, Nr, [CERTREQ] (exchange continues) or 1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3) <--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2) 2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag) <--- HDR(A,0,0) SAr1, KEr, Nr, [CERTREQ] (major=2) (exchange continues) or 1. HDR(A,0,0) SAi1, KEi, Ni ---> <--- HDR(A,0,0) N(COOKIE) 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) (initiator decides to ignore the error message as it is unprotected) 3. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) 4. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) 5. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) 6. Initiator gives up, as the other end does not reply. or 1. HDR(A,0,0) SAi1, KEi, Ni ---> <--- HDR(A,0,0) N(COOKIE) 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie) <--- HDR(A,0,0) N(INVALID_KE_PAYLOAD) (initiator notices, that it has wrong KEi, changes it to new, still keeps cookie, as this is simply retransmission of packet) 3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit) <--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ] (exchange continues) or 1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3) <--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2) 2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag) <--- HDR(A,0,0) N(COOKIE) (major=2) 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie, major=2, version flag set) <--- HDR(A,0,0) N(INVALID_KE_PAYLOAD) (major=2) (initiator notices, that it has wrong KEi, changes it to new, still keeps cookie, as this is simply retransmission of packet) 3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit, major=2, version flag set)) <--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ] (major=2) (exchange continues) or the last one optimized: 1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3) <--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2) 2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag) <--- HDR(A,0,0) N(COOKIE),N(INVALID_KE_PAYLOAD) (major=2) 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (initiator notices, that it has wrong KEi, changes it to new, still keeps cookie and major = 2, as this is simply retransmission of packet) 3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit, major=2, version flag set)) <--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ] (major=2) (exchange continues) So the error handling for the first packet would be: If responder detects any error when processing the initiators IKE_SA_INIT packet, it does not allocate any state, it simply returns error message having same SPI-I, SPI-R and message id fields (i.e. SPI-R and message id will be 0). The message contents will be the error notification(s) about the error (COOKIE, NO_PROPOSAL_CHOSEN, INVALID_MAJOR_VERSION, INVALID_KE_PAYLOAD etc). When initiator gets an error notification back from the responder if the notification gives any indication how to fix the situation (COOKIE -- add N(COOKIE) to request; INVALID_KE_PAYLOAD -- change KEi payload to use requested group; INVALID_MAJOR_VERSION -- fall back to lower version etc), then it should act accordingly and retransmit its packet using same SPI-I and message id. It might need to fix it's packet multiple times to get it right (i.e. first fall back to older version, then add N(COOKIE), then in addition to those already done change the group to different etc). It SHOULD not fail the negotation based on the unauthenticated notification. The negotiation will fail only after it times out. Responder SHOULD keep a retransmit packet buffer for incoming first packets, but it can only retransmit its reply to the initiator if the packet contents sent by the initiator is exactly same as what was in the packet which generated that reply. Responder MUST also check the source and destination IP-addresses and ports when checking if the packet is same. If the IP-addresses or ports are changed responder needs to process the packet again, instead of using the stored reply. This is because the contents of NAT_DETECTION_*_IP notifications will change if the IP-addresses or ports changes, thus the reply will not be same. When the initiator changes the packet, the responder needs to process the packet again (it might succeed now, or generate new different error notification(s)). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 8 06:59:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13656 for ; Fri, 8 Oct 2004 06:59:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsKi-00028U-AY; Fri, 08 Oct 2004 06:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsJn-0001oe-Al for ipsec@megatron.ietf.org; Fri, 08 Oct 2004 06:49: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 GAA13014 for ; Fri, 8 Oct 2004 06:49:45 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsTh-0003bp-Jf for ipsec@ietf.org; Fri, 08 Oct 2004 07:00:02 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i98AnjRC004062 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Oct 2004 13:49:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i98Ani8v004059; Fri, 8 Oct 2004 13:49:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16742.28872.528166.364677@fireball.kivinen.iki.fi> Date: Fri, 8 Oct 2004 13:49:44 +0300 From: Tero Kivinen To: "Dondeti, Lakshminath" Subject: Re: [Ipsec] Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)combina tion In-Reply-To: <416613CD.7040806@nortelnetworks.com> References: <16741.24908.236436.231881@fireball.kivinen.iki.fi> <416613CD.7040806@nortelnetworks.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Dondeti, Lakshminath writes: > Wouldn't this work? It would, and as you can see from my second email, this is something I actually proposed to be probably the best way to go. > If an implementation chooses to include KEi in "cookie" computation, the > initiator would have to start all over, i.e., without N(COOKIE). Or actually in that case the responder would send new N(COOKIE) after the KE changed, and the initiator would need to update to using that new cookie. > Starting all over might not be such a bad idea, because we can't assume > that an implementation won't do that. When you start over you will need to do new cookie exchange every time, as the SPI-I is going to be included in the cookie. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 8 12:55:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10378 for ; Fri, 8 Oct 2004 12:55:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxvK-0004YO-24; Fri, 08 Oct 2004 12:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxu2-0004H3-6H for ipsec@megatron.ietf.org; Fri, 08 Oct 2004 12:47:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09906 for ; Fri, 8 Oct 2004 12:47:33 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFy3q-0002gh-9f for ipsec@ietf.org; Fri, 08 Oct 2004 12:57:52 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98GlEu9051885; Fri, 8 Oct 2004 09:47:14 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16739.43847.865201.27545@fireball.kivinen.iki.fi> References: <16738.24637.920951.642302@fireball.kivinen.iki.fi> <16739.43847.865201.27545@fireball.kivinen.iki.fi> Date: Fri, 8 Oct 2004 09:47:22 -0700 To: Tero Kivinen From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:22 AM +0300 10/6/04, Tero Kivinen wrote: >I do not think we need to take any other changes than what is >required, and we can refer those extensions (AES) by just refering the >rfc defining them. > >I still think that it would be "Update" to the RFC2409 if we simply >say that AES (RFC3602) is now MUST to implement cipher. I'm fine with this as long as this document is only updating the crypto stuff, not rolling in everything else we have done to IKEv1 in the past six years. Does anyone have any objections to that? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Oct 9 12:54:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25220 for ; Sat, 9 Oct 2004 12:54:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGKS7-0006mz-MA; Sat, 09 Oct 2004 12: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 1CGKRc-0006c7-4d for ipsec@megatron.ietf.org; Sat, 09 Oct 2004 12:51: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 MAA25088 for ; Sat, 9 Oct 2004 12:51:41 -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 1CGKbl-0001T5-Br for ipsec@ietf.org; Sat, 09 Oct 2004 13:02:13 -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 i99GkUd08006 for ; Sat, 9 Oct 2004 12:46:30 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i99Gmbif020389 for ; Sat, 9 Oct 2004 12:48:37 -0400 (EDT) Received: from unknown(80.41.247.214) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5uaOZN; Sat, 9 Oct 04 12:48:35 -0400 Date: Sat, 09 Oct 2004 17:40:16 +0000 To: "Ipsec" From: "Kent" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nmerdhkmplnrtrsntsfh" X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ipsec] Incoming message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------nmerdhkmplnrtrsntsfh Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------nmerdhkmplnrtrsntsfh Content-Type: application/octet-stream; name="Your_complaint.hta" Content-Disposition: attachment; filename="Your_complaint.hta" Content-Transfer-Encoding: base64 ----------nmerdhkmplnrtrsntsfh Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------nmerdhkmplnrtrsntsfh-- From ipsec-bounces@ietf.org Mon Oct 11 08:13:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29630 for ; Mon, 11 Oct 2004 08:13:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGyxF-0004tP-6e; Mon, 11 Oct 2004 08:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGysN-0003mx-9K for ipsec@megatron.ietf.org; Mon, 11 Oct 2004 08:02:03 -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 IAA28199 for ; Mon, 11 Oct 2004 08:02:01 -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 1CGz2q-0006CF-7p for ipsec@ietf.org; Mon, 11 Oct 2004 08:12:56 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i9BBuid17242 for ; Mon, 11 Oct 2004 07:56:45 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i9BBwqrm020583 for ; Mon, 11 Oct 2004 07:58:52 -0400 (EDT) Received: from unknown(80.41.204.15) by nutshell.tislabs.com via csmap (V6.0) id srcAAAzSaWiO; Mon, 11 Oct 04 07:58:47 -0400 Date: Mon, 11 Oct 2004 12:50:23 +0000 To: "Ipsec" From: "Kent" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hlyhjmuucoxzmttkuicr" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] 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 ----------hlyhjmuucoxzmttkuicr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------hlyhjmuucoxzmttkuicr Content-Type: text/html; name="Message.exe.htm" Content-Disposition: attachment; filename="Message.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: Message.exe
Virus name: W32/Bagle.aa@MM

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

----------hlyhjmuucoxzmttkuicr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------hlyhjmuucoxzmttkuicr-- From ipsec-bounces@ietf.org Mon Oct 11 12:26:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19597 for ; Mon, 11 Oct 2004 12:26:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH2r2-0004Qc-1T; Mon, 11 Oct 2004 12:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH2nR-00034t-Mp for ipsec@megatron.ietf.org; Mon, 11 Oct 2004 12:13:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18847 for ; Mon, 11 Oct 2004 12:13:10 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH2xz-0002PF-R4 for ipsec@ietf.org; Mon, 11 Oct 2004 12:24:08 -0400 Received: from SriniSony (dhcp-71.intoto.com [10.1.5.71]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i9BGDcRP002678; Mon, 11 Oct 2004 09:13:38 -0700 Message-ID: <005f01c4afad$321c1240$1411a8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: "Tero Kivinen" References: <16741.24908.236436.231881@fireball.kivinen.iki.fi><145001c4acdd$8fffc370$1411a8c0@SriniSony> <16742.28077.940436.338326@fireball.kivinen.iki.fi> Subject: Re: [Ipsec] Question about N(COOKIE) andN(INVALID_KE_PAYLOAD)combination Date: Sun, 10 Oct 2004 18:43:46 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.4 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Message ID: I also noticed the statement 'The IKE_SA initial setup messages will always be numbered 0 and 1'. I think, these are values if there are no errors in leading to SA establishment. I am hoping that, no implementation would reject the initial exchanges if the message IDs are not numbered 0 and 1. Actually, in EAP case, the message IDs go beyond 1, before it completes AUTH exchange. There are some errors and indications which can be corrected by the IKE automatically and there are other type of errors, which require changes by the administartor. In the later case, I feel, there is no need to maintain the state. For example, NO_PROPOSAL_CHOSEN kind of errors can only be corrected by changes to the policy configuration. Any new IKE transaction starts with new SPI value and message ID as 0. Here, there is no problem of DoS attack, as the attacker has to guess the new SPI and that is difficult for an attacker to do that kind of guessing. In the case of errors, which can be corrected automatically, such as INVALID_KE_PAYLOAD, I guess different intrepreations are possible due to no explicit descripton in the IKEv2 draft. Whichever is the solution should be interoperable and should not lead to simple DoS attacks. You are indicating one solution ie if responder chooses SPI value, then the responder is maintaining the state and if is is zero, responder does not maintain the state. To protect against DoS attacks, I feel that, if the responder is not maintaing the state (it indicates by keeping the responder SPI to 0), then the initiator should start the transaction with new initiator SPI value. If the Initiator chooses the same SPI value, it becomes easier for an attacker to send error notification, if the attacker is intelligently records the previous initiator SPI. Keeping the above issues and interoperability issues in mind, following behaviour at the Initiator side, I feel, would work fine in all cases (This suggestion is similar to one of suggestions you made) * Initiator should send the IKE_SA_INIT exchange with new SPI and message ID 0, when the response message contains error indication. Note: Retransmision case is different. In retransmission case, either request is missed or response is missed. In that case, the initiator would repeat the same request as is. I would assume, implementations, to simplify the complexiy would divide the retransmission logic from the main IKE state machine. Retransmission would be taken care of retransmission logic. * Responder need not generate its SPI, when it sends error notification as part of IKE_SA_INIT response. With this, combined logic of COOKIE and INVALID_KE_PAYLOAD appear like this on the wire. 1. HDR(A,0,0) SAi1, KEi, Ni ---> <--- HDR(A,0,0) N(COOKIE) 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> <--- HDR(A',X,0) N(INVALID_KE_PAYLOAD) 3. HDR(A',0,0) SAi1, KEi(new), Ni ---> <--- HDR(A',0,0) N(COOKIE2) 4. HDR(A',0,0) N(COOKIE2), SAi1, KEi(new), Ni ---> <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ] Even though above example is given with INVALID_KE_PAYLOAD, it is applicable for other messages such as NO_PROPOSAL_CHOSEN. For example, it will appear like this. 1. HDR(A,0,0) SAi1, KEi, Ni ---> <--- HDR(A,0,0) N(COOKIE) 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> <--- HDR(A,X,0) N(NO_PROPOSAL_CHOSEN) Proposals in the policies are corrected. 3. HDR(A',0,0) SAi1, KEi, Ni ---> <--- HDR(A',0,0) N(COOKIE2) 4. HDR(A',0,0) N(COOKIE2), SAi1, KEi, Ni ---> <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ] In my opinion, Initiator can even generate new SPI value in transaction 2 ie while sending IKE_SA_INIT request with N(COOKIE). With this, even if the attacker records INIT_SA_RESPONSE with N(COOKIE)and replays the same, the exchange does not succeed. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "Tero Kivinen" To: "Srinivasa Rao Addepalli" Cc: Sent: Friday, October 08, 2004 3:36 AM Subject: Re: [Ipsec] Question about N(COOKIE) andN(INVALID_KE_PAYLOAD)combination > Srinivasa Rao Addepalli writes: >> Initiator Responder >> 1. HDR(A,0,0), SAi1, KEi, Ni--> >> <--- HDR(A,0,0)N(COOKIE) >> 2. HDR(A,0,0), N(COOKIE), SAi1, KEi, Ni-----> >> <---- HDR(A,B,0) N(INVALID_KE_PAYLOAD) >> (At this time, state is created by both responder too.) >> 3. HDR(A,B,1), SAi1, KEi(new), Ni-------> >> <----- HDR(A,B,1), SAr1, KEr, Nr. [CERTREQ] >> >> I feel that Initiator need to choose message id 1 in transaction 3. > > But the setion 2.2 says that IKE_SA initial setup message will always > be number 0 and 1, and in your case the IKE_AUTH coming after the 3rd > transaction would have message id 2.... > >> if transaction 3 uses message ID 0, it is possible that responder >> might return the previous response as message id is same. > > Yes, that happens unless, it understand this case separately. > >> If the responder chooses not to create the state in transaction 2, >> it would be treating message ID 0 as new transaction and that would >> work. > > In that case it would need to send new N(COOKIE) too, as in my > example. Otherwise it would not know that this is node that has talked > to him before. > >> Since, initiator would not know the behaviour of the responder, it >> is better if Initiator chooses new message ID for transaction 3. > > If the responder allocated SPI-R (B) then it means that it has created > state, and if the responder is still using SPI-R of 0, as in N(COOKIE) > exchange, then it knows that the other end has not created any state > yet. > > One (not so good) option would also be that in the INVALID_KE_PAYLOAD > case the initiator MUST select new SPI-I, i.e. instead of A it would > use A', i.e. start new negotiation, and the responder will simply > consider the N(INVALID_KE_PAYLOAD) as an error, and refuse to process > any further messages to the SA. > > I.e. the normal INVALID_KE_PAYLOAD exchance without cookies would go: > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > <--- HDR(A,X,0) N(INVALID_KE_PAYLOAD) > 2. HDR(A',0,0) SAi1, KEi(new), Ni ---> > <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ] > > and combined with cookies it would be: > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > <--- HDR(A,0,0) N(COOKIE) > 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> > <--- HDR(A,X,0) N(INVALID_KE_PAYLOAD) > 3. HDR(A',0,0) SAi1, KEi(new), Ni ---> > <--- HDR(A',0,0) N(COOKIE2) > 4. HDR(A',0,0) N(COOKIE2), SAi1, KEi(new), Ni ---> > <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ] > > Note, that we need second cookie exchange, as the SPI-I has changed, > thus the cookie given in the first step does not work for the A'. > > Note, that I used SPI-R of X in the N(INVALID_KE_PAYLOAD) error, as I > do not know if we need to use 0 or allocate something there. > > The first packets before SPI-R is allocated by the responder and > before the initiator also starts using that, must use different > retransmission and window rules anyways. I.e. we must check if the > SPI-R is 0, and if so we must use the whole packet to detect > retranmissions. So our retranmission policy needs to be so that if the > packet is exactly same than previous time, we can retransmit our old > packet back. If it is changed then we need to process it again (it > might be new negotiation from some one else simply using the same > SPI-I than the previous user). > > The responder could optimize things a little bit, by processing the > SAi1 already in the first step, i.e. > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > <--- HDR(A,0,0) N(COOKIE), N(INVALID_KE_PAYLOAD) > 2. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> > <--- HDR(A,B,0) SAr1, KEr, Nr, [CERTREQ] > > but this would open the responder to the DoS attacks as it now needs > to do something more complicated than only request cookie for the > first packet. > > Actually the whole error handling in the first packet is not really > defined well. The 2.21 does not mention anything about that. I would > say the best option is that if anything goes wrong when processing the > first IKE_SA_INIT packet from initiator, we simply return packet with > zero SPI-R cookie, and containing the error notification(s), and then > responder simply deletes all information about the actual exchange. > > It can use global retransmission system retransmitting exactly same > reply back if it receives exactly same request, but nothing more. > > If the message is different than previous one, we must always process > it, just like any new message. Initiator should keep the SPI-I same > all the time as otherwise the N(COOKIE) payloads do not match. Also > the exchange fails only after it times out, not because of > unauthenticated notifications. > > I.e: > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > (lost) <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > 2. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) > <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > (initiator decides to ignore the error message as it is unprotected) > 3. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) > <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > 4. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) > <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > 5. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) > <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > 6. Initiator gives up, as the other end does not reply. > > or > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> (bit error, or attacker modifying the > packet in transit causing invalid syntax) > <--- HDR(A,0,0) N(INVALID_SYNTAX) > 2. HDR(A,0,0) SAi1, KEi, Ni ---> (retransmit) > <--- HDR(A,0,0) SAr1, KEr, Nr, [CERTREQ] > (exchange continues) > > or > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3) > <--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2) > 2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag) > <--- HDR(A,0,0) SAr1, KEr, Nr, [CERTREQ] (major=2) > (exchange continues) > > or > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > <--- HDR(A,0,0) N(COOKIE) > 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie) > <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > (initiator decides to ignore the error message as it is unprotected) > 3. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit) > <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > 4. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit) > <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > 5. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit) > <--- HDR(A,0,0) N(NO_PROPOSAL_CHOSEN) > 6. Initiator gives up, as the other end does not reply. > > or > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > <--- HDR(A,0,0) N(COOKIE) > 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie) > <--- HDR(A,0,0) N(INVALID_KE_PAYLOAD) > (initiator notices, that it has wrong KEi, changes it to new, still > keeps cookie, as this is simply retransmission of packet) > 3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit) > <--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ] > (exchange continues) > > or > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3) > <--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2) > 2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag) > <--- HDR(A,0,0) N(COOKIE) (major=2) > 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> (retransmit with cookie, > major=2, version flag set) > <--- HDR(A,0,0) N(INVALID_KE_PAYLOAD) (major=2) > (initiator notices, that it has wrong KEi, changes it to new, still > keeps cookie, as this is simply retransmission of packet) > 3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit, major=2, > version flag set)) > <--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ] (major=2) > (exchange continues) > > or the last one optimized: > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> (using major version 3) > <--- HDR(A,0,0) N(INVALID_MAJOR_VERSION) (major=2) > 2. HDR(A,0,0) SAi1, KEi, Ni ---> (major=2, setting version flag) > <--- HDR(A,0,0) N(COOKIE),N(INVALID_KE_PAYLOAD) (major=2) > 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> > (initiator notices, that it has wrong KEi, changes it to new, still > keeps cookie and major = 2, as this is simply retransmission of packet) > 3. HDR(A,0,0) N(COOKIE), SAi1, KEi(new), Ni ---> (retransmit, major=2, > version flag set)) > <--- HDR(A,0,0) SAir, KEr, Nr, [CERTREQ] (major=2) > (exchange continues) > > So the error handling for the first packet would be: > > If responder detects any error when processing the initiators > IKE_SA_INIT packet, it does not allocate any state, it simply > returns error message having same SPI-I, SPI-R and message id > fields (i.e. SPI-R and message id will be 0). The message > contents will be the error notification(s) about the error > (COOKIE, NO_PROPOSAL_CHOSEN, INVALID_MAJOR_VERSION, > INVALID_KE_PAYLOAD etc). > > When initiator gets an error notification back from the > responder if the notification gives any indication how to fix > the situation (COOKIE -- add N(COOKIE) to request; > INVALID_KE_PAYLOAD -- change KEi payload to use requested > group; INVALID_MAJOR_VERSION -- fall back to lower version > etc), then it should act accordingly and retransmit its packet > using same SPI-I and message id. It might need to fix it's > packet multiple times to get it right (i.e. first fall back to > older version, then add N(COOKIE), then in addition to those > already done change the group to different etc). > > It SHOULD not fail the negotation based on the unauthenticated > notification. The negotiation will fail only after it times > out. > > Responder SHOULD keep a retransmit packet buffer for incoming > first packets, but it can only retransmit its reply to the > initiator if the packet contents sent by the initiator is > exactly same as what was in the packet which generated that > reply. Responder MUST also check the source and destination > IP-addresses and ports when checking if the packet is same. If > the IP-addresses or ports are changed responder needs to > process the packet again, instead of using the stored reply. > This is because the contents of NAT_DETECTION_*_IP > notifications will change if the IP-addresses or ports > changes, thus the reply will not be same. When the initiator > changes the packet, the responder needs to process the packet > again (it might succeed now, or generate new different error > notification(s)). > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 12 00:12:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28309 for ; Tue, 12 Oct 2004 00:12:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHDvE-0003ew-5A; Tue, 12 Oct 2004 00:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHDr8-0002LU-OH for ipsec@megatron.ietf.org; Tue, 12 Oct 2004 00:01: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 AAA27425 for ; Tue, 12 Oct 2004 00:01:43 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.205] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHE1n-0003yl-14 for ipsec@ietf.org; Tue, 12 Oct 2004 00:12:48 -0400 Received: by mproxy.gmail.com with SMTP id 79so444046rnl for ; Mon, 11 Oct 2004 21:01:44 -0700 (PDT) Received: by 10.38.65.2 with SMTP id n2mr687428rna; Mon, 11 Oct 2004 21:01:44 -0700 (PDT) Received: by 10.38.99.19 with HTTP; Mon, 11 Oct 2004 21:01:44 -0700 (PDT) Message-ID: <92847de604101121016ddec46a@mail.gmail.com> Date: Tue, 12 Oct 2004 09:31:44 +0530 From: Madhukesh Jayadevaiah To: ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Multicast Traffic support within IPSec VPN Tunnel? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Madhukesh Jayadevaiah List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Can IPSec VPN Site-to-Site tunnel carry Multicast traffic or Broadcast traffic with in the tunnel? If yes, is it just the bare IPSec protocol which can allow Multicast or Broadcast traffic to pass through the tunnel or do GRE or any such protocol is mandatory? If No, why IPSec by itself can not carry Multicast or Broadcast traffic through the tunnel? Looking forward for reply. Thanks and Regards, Madhukesh. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 12 08:02:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11491 for ; Tue, 12 Oct 2004 08:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHLAz-00074Z-EO; Tue, 12 Oct 2004 07:50:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHL7W-00068g-9t for ipsec@megatron.ietf.org; Tue, 12 Oct 2004 07:47:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10392 for ; Tue, 12 Oct 2004 07:47:09 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHLIE-0002x3-I3 for ipsec@ietf.org; Tue, 12 Oct 2004 07:58:15 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i9CBl5gI011774 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Oct 2004 14:47:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i9CBl37H011771; Tue, 12 Oct 2004 14:47:03 +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: <16747.50231.767484.671819@fireball.kivinen.iki.fi> Date: Tue, 12 Oct 2004 14:47:03 +0300 From: Tero Kivinen To: "Srinivasa Rao Addepalli" Subject: Re: [Ipsec] Question about N(COOKIE) andN(INVALID_KE_PAYLOAD)combination In-Reply-To: <005f01c4afad$321c1240$1411a8c0@SriniSony> References: <16741.24908.236436.231881@fireball.kivinen.iki.fi> <145001c4acdd$8fffc370$1411a8c0@SriniSony> <16742.28077.940436.338326@fireball.kivinen.iki.fi> <005f01c4afad$321c1240$1411a8c0@SriniSony> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 42 min X-Total-Time: 50 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Srinivasa Rao Addepalli writes: > Message ID: I also noticed the statement 'The IKE_SA initial setup messages will > always be numbered 0 and 1'. I think, these are values if there are no errors > in leading to SA establishment. I am hoping that, no implementation would reject > the initial exchanges if the message IDs are not numbered 0 and 1. Actually, in EAP > case, the message IDs go beyond 1, before it completes AUTH exchange. For the EAP case, I think it is quite clear that additional IKE_AUTH exchanges have new message IDs. For the IKE_SA_INIT, I think the protocol is simplier if we always assume that the message id is 0, and the responder does not store any state before it can successfully reply to the IKE_SA_INIT packet. > There are some errors and indications which can be corrected by the IKE > automatically and there are other type of errors, which require changes by > the administartor. In the later case, I feel, there is no need to maintain the state. > For example, NO_PROPOSAL_CHOSEN kind of errors can only be corrected > by changes to the policy configuration. Any new IKE transaction starts with new > SPI value and message ID as 0. Here, there is no problem of DoS attack, as the > attacker has to guess the new SPI and that is difficult for an attacker to do that kind > of guessing. How does now SPIi protect against DoS attacks? If he can see the first packet having SPIi in it, he can se the new SPIi too. If he cannot see any traffic he needs to guess the right SPIi in any case and the attack cost remains about same. > In the case of errors, which can be corrected automatically, such as > INVALID_KE_PAYLOAD, I guess different intrepreations are possible due to > no explicit descripton in the IKEv2 draft. Whichever is the solution should be > interoperable and should not lead to simple DoS attacks. You are indicating > one solution ie if responder chooses SPI value, then the responder is maintaining > the state and if is is zero, responder does not maintain the state. Actually I think it is better that responder never keeps state in that case, it simply returns error and forgets the exchange. The initiator will then fix the problem and try again (and he can and should use same SPIi as the responder have forgotten the previous packet, so there is no reason why not to use old SPIi, using old SPIi keeps the cookies valid in case cookie exchange was needed). > To protect against DoS attacks, I feel that, if the responder is not maintaing the > state (it indicates by keeping the responder SPI to 0), then the initiator should > start the transaction with new initiator SPI value. If the Initiator chooses the same > SPI value, it becomes easier for an attacker to send error notification, if the attacker > is intelligently records the previous initiator SPI. If the attacker can see the first exchange, he can also see the next exchange, thus no point of changing SPIi there. I do not think the change of SPIi will really get you any protection against DoS, but it will cost you several round trips again, as you need to do cookie exchange again for each new modification because of the new SPIi. It also makes the N(COOKIE) notification a special case where the initiator MUST keep the same SPIi. So easiest way to implement it is to say that the SPIi stays same as long as the initiator continues trying, and responder will forget the packet immediately if it returned error for it (COOKIE, INVALID_KE_PAYLOAD, INVALID_MAJOR_VERSION etc). > * Initiator should send the IKE_SA_INIT exchange with new SPI and > message ID 0, when the response message contains error indication. That will not work for the N(COOKIE) error notification, as it is already explained in the draft and it mandates that you keep the SPIi same. > * Responder need not generate its SPI, when it sends error notification as part of > IKE_SA_INIT response. I would say responder MUST NOT generate its SPI when it sending error notifications as part of IKE_SA_INIT response. That would be consistent with the N(COOKIE) error, i.e. the N(COOKIE) would not be a special case, but just using same rules as other errors. There is no benefit for initiator to change SPIi, or responder to allocate SPIr in error cases, but for N(COOKIE) error we cannot change SPIi and we cannot allocate SPIr, so lets keep the processing same for all error messages including N(COOKIE). > With this, combined logic of COOKIE and INVALID_KE_PAYLOAD appear like this > on the wire. > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > <--- HDR(A,0,0) N(COOKIE) > 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> > <--- HDR(A',X,0) N(INVALID_KE_PAYLOAD) > 3. HDR(A',0,0) SAi1, KEi(new), Ni ---> > <--- HDR(A',0,0) N(COOKIE2) > 4. HDR(A',0,0) N(COOKIE2), SAi1, KEi(new), Ni ---> > <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ] This will add one extra round trip, one extra half-open SA in the responder end (the one returning INVALID_KE_PAYLOAD), which need to be timed out and so one. Not very clean solution. > Even though above example is given with INVALID_KE_PAYLOAD, it is applicable for > other messages such as NO_PROPOSAL_CHOSEN. For example, it will appear like this. > > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > <--- HDR(A,0,0) N(COOKIE) > 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> > <--- HDR(A,X,0) N(NO_PROPOSAL_CHOSEN) We cannot accept the NO_PROPOSAL_CHOSEN directly, as it would open DoS attack by just sending one packet. We need to keep on sending until the initiator times out. After that we will of course start new negitation using differnt SPIi, as the old one has already failed. > In my opinion, Initiator can even generate new SPI value in transaction 2 ie while sending > IKE_SA_INIT request with N(COOKIE). With this, even if the attacker > records INIT_SA_RESPONSE with N(COOKIE)and replays the same, the exchange > does not succeed. If initiator will genreate new SPIi, then responder will send new N(COOKIE) back again, as the old one does not match (it contains SPIi in it). The initiator will detect that the replayed IKE_SA_INIT response do not give any new information how to continue processing the message, so it will simply continue sending the last packet it has sent out (having the N(COOKIE)) until the other end responds. If the attacker send fake N(FAKECOOKIE) notification back before the responder sends its iwn N(COOKIE) then the initiator will first try with N(FAKECOOKIE) and when it gets the real N(COOKIE) exchange, it notices that ok, this changes state again, so it will send new packet with N(COOKIE) and the responder will only continue with the proper N(COOKIE) exchange: Initiator Attacker Responder 1. HDR(A,0,0) SAi1, KEi, Ni ---> 2. <--- HDR(A,0,0) N(FAKECOOKIE) Responder gets the 1. packet and replies 3. <--- HDR(A,0,0) N(COOKIE) Initiator replies using attackers cookie 4. HDR(A,0,0) N(FAKECOOKIE), SAi1, KEi, Ni ---> Responder will either ignore the message with wrong cookie, or reply with similar message than in 3, i.e. sends the right cookie. Initiator gets the real cookie from responder notices it is different, and replies with that 5. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> Attacker tries to confuse things more, and sends new N(FAKECOOKIE) message 6. <--- HDR(A,0,0) N(FAKECOOKIE) Initiator sees again different cookie, and tries with that. 7. HDR(A,0,0) N(FAKECOOKIE), SAi1, KEi, Ni ---> In the mean while the responder gets the packet sent in 5, and notices that the cookie is valid and replies with his message 8. <--- HDR(A,B,0) SAr1, KEr, Nr When initiator gets packet sent in step 7 it either ignores it or replies with message 3, with right cookie. When initiator gets the message 8 it moves to the IKE_AUTH phase, and after that it may ignore all IKE_SA_INIT messages. If it wants to protect from all DoS attacks it still continues looking for IKE_AUTH messages and it will move to the IKE_AUTH phase for each valid IKE_SA_INIT message it gets, and tries to finish them all. When one of those IKE_AUTH exchanges finishes, all other half open IKE SAs with same SPI-i A are deleted. If we continue example here. Attacker decides he wants to cause even more problems and sends 2 more valid looking IKE_SA_INIT replies. 9. <--- HDR(A,X,0) SAr1', KEr', Nr' 10. <--- HDR(A,Y,0) SAr1'', KEr'', Nr'' Initiator will process them all, and start IKE_AUTH for all of them. All of the packets are encrypted with different key, and MAC'ed with different key. Each of those require a separate Diffie-Hellman, as the KEr, KEr', KEr'' received from other end are different. 11. HDR(A,B,1) SK1{IDi,AUTH,SAi2,TSi,TSr} ---> 12. HDR(A,X,1) SK2{IDi,AUTH,SAi2,TSi,TSr} ---> 13. HDR(A,Y,1) SK3{IDi,AUTH,SAi2,TSi,TSr} ---> Attacker cannot reply to any of those as it does not know how to generate valid AUTH paylod for reply packet. He do know how to generate valid MAC and how to encrypt the packet, but he cannot authenticate himself. Responder will ignore unknown SPIr values X and Y, and reply to the SPIr B. 14. <--- HDR(A,B,1) SK1{IDr, AUTH, SAr2, TSi, TSr} Initiator receives the valid packet authenticating the IKE SA, and deletes IKE SA (A,X) and (A,Y), at the same time when it marks (A,B) as finished. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 12 11:39:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01864 for ; Tue, 12 Oct 2004 11:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOcm-0002WE-Sn; Tue, 12 Oct 2004 11:31:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOZ8-0001TB-Mq for ipsec@megatron.ietf.org; Tue, 12 Oct 2004 11:27:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00720 for ; Tue, 12 Oct 2004 11:27:53 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOjs-0007iy-OP for ipsec@ietf.org; Tue, 12 Oct 2004 11:39:02 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i9CFMYd15672 for ; Tue, 12 Oct 2004 11:22:35 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i9CFOjni029631 for ; Tue, 12 Oct 2004 11:24:45 -0400 (EDT) Received: from woodstock.binhost.com(144.202.240.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAN8aO25; Tue, 12 Oct 04 11:24:43 -0400 Received: (qmail 16819 invoked by uid 0); 12 Oct 2004 15:27:26 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.242.83) by woodstock.binhost.com with SMTP; 12 Oct 2004 15:27:26 -0000 Message-Id: <6.1.2.0.2.20041012112549.04c3ab40@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Oct 2004 11:27:01 -0400 To: stully@qantas.com.au, ipsec@lists.tislabs.com From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.2 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ipsec] Re: AES standard with 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 That document is in the RFC Editor queue. It should be come an RFC soon. There is also an specification for using AES in CBC more and another for using AES in GCM more. Russ At 07:06 PM 10/7/2004, stully@qantas.com.au wrote: >Hi, > >Can you tell me if a standard exists yet for the use of Advanced Encryption >Standard (AES) with IPsec. If not, can you either give me an update on >where this is at, or point me to the standard if it now exists. > >I looked at >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-05.txt >but this document expired approximately April 2004 I think. > >Thanks, > >Shane Tully >Infrastructure Security Architect >Qantas Airways. > > > > >******************* Confidentiality and Privilege Notice ******************* > >This e-mail is intended only to be read or used by the addressee. It is >confidential and may contain legally privileged information. If you are not >the addressee indicated in this message (or responsible for delivery of the >message to such person), you may not copy or deliver this message to anyone, >and you should destroy this message and kindly notify the sender by reply >e-mail. Confidentiality and legal privilege are not waived or lost by reason >of mistaken delivery to you. > >Qantas Airways Limited >ABN 16 009 661 901 > >Visit Qantas online at http://qantas.com > >**************************************************************************** _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 15 07:48:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20032 for ; Fri, 15 Oct 2004 07:48:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIQWD-00047d-Lt; Fri, 15 Oct 2004 07:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIQVh-00040G-Pg for ipsec@megatron.ietf.org; Fri, 15 Oct 2004 07:44:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19842 for ; Fri, 15 Oct 2004 07:44:36 -0400 (EDT) Received: from ouse.qinetiq.com ([192.102.214.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIQgz-0004qv-7k for ipsec@ietf.org; Fri, 15 Oct 2004 07:56:22 -0400 Received: (qmail 19089 invoked by uid 1011); 15 Oct 2004 11:44:00 -0000 Received: from RACASE@qinetiq.com by ouse.qinetiq.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.75-1. spamassassin: 2.64. Clear:RC:1(10.0.5.21):. Processed in 0.133862 secs); 15 Oct 2004 11:44:00 -0000 Received: from unknown (HELO frome.uncdmz.qinetiq.com) (10.0.5.21) by ouse.qinetiq.com with SMTP; 15 Oct 2004 11:43:59 -0000 Received: from allen.qinetiq.com (Not Verified[10.0.20.10]) by frome.uncdmz.qinetiq.com with NetIQ MailMarshal (v5.5.6.6) id ; Fri, 15 Oct 2004 12:43:58 +0100 Message-ID: <4B399B8DBA86D411BB3500508B9566FF0EF19958@mal-mail-1.dera.gov.uk> From: Case Richard A To: "'ipsec@ietf.org'" Date: Fri, 15 Oct 2004 12:43:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) X-GATEWAY: Unclassified X-Spam-Score: 0.3 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Subject: [Ipsec] Proposal and Transform Payloads X-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="===============1133746257==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1133746257== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B2AB.FFACADB8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B2AB.FFACADB8 Content-Type: text/plain I am looking for clarification of RFC 2408 - I hope you can help! 1. It is implied but nowhere stated that the Proposal and Transform numbers must start at one (and not zero) and monotonically increase. Is this the case? 2. Does the order of preference decrease with increasing Proposal/Transform numbers? i.e. 1 is most preferred, 2 is next most preferred, etc... 3. Can you include the same Data Attribute Type multiple times in the SA Attribute field of a Transform Payload, or do different options need to be included in separate Transform Payloads? E.g. In the Path 2, Main Mode, Phase I exchange can I include two data attributes of type 3 (authentication method - let's say for argument 2-DSS & 3-RSA signatures) in the same Transform Payload? Many thanks, Richard Richard Case Communication Engineer The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes. ------_=_NextPart_001_01C4B2AB.FFACADB8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I am looking for clarification of RFC 2408 - I hope you can help!

 

    =20
  1. It is implied but now= here =20 stated that the Proposal and Transform numbers must start at one (= and not =20 zero) and monotonically increase. Is this the case?
    2. =20
  2. Does the order of pre= ference decrease =20 with increasing Proposal/Transform numbers? i.e. 1 is most preferr= ed, 2 is =20 next most preferred, etc...
    3. =20
  3. Can you include the s= ame Data =20 Attribute Type multiple times in the SA Attribute field of a Trans= form =20 Payload, or do different options need to be included in separate T= ransform =20 Payloads? E.g. In the Path 2, Main Mode, Phase I exchange can I in= clude =20 two data attributes of type 3 (authentication method - let's =20 say for argument 2-DSS & 3-RSA signatures) in the same Transfo= rm =20 Payload?

 

Many thanks,

Richard

Richard Case
Communication Engineer

 

The Information contained in this E-Mail and any subsequent correspo= ndence=20 is private and is intended solely for the intended recipient(s).
For t= hose=20 other than the recipient any disclosure, copying, distribution, or any ac= tion=20 taken or omitted to be taken in reliance on such information is prohibite= d and=20 may be unlawful.
Emails and other electronic communication with QinetiQ may be=20 monitored.  Calls to QinetiQ may be recorded for quality contro= l,=20 regulatory and monitoring purposes.
------_=_NextPart_001_01C4B2AB.FFACADB8-- --===============1133746257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1133746257==-- From ipsec-bounces@ietf.org Fri Oct 15 17:22:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23255 for ; Fri, 15 Oct 2004 17:22:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYxR-0005YE-2A; Fri, 15 Oct 2004 16:45:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYSZ-0008FJ-SN for ipsec@megatron.ietf.org; Fri, 15 Oct 2004 16:13:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08023 for ; Fri, 15 Oct 2004 16:13:53 -0400 (EDT) Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIYe0-00011S-3O for ipsec@ietf.org; Fri, 15 Oct 2004 16:25:44 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 00A2D5B79E for ; Fri, 15 Oct 2004 23:13:22 +0300 (EEST) Received: from unknown[10.128.128.81]:59253 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.146 Release) with SMTP; Fri, 15 Oct 2004 20:13:19 -0000 Received: (qmail 16668 invoked from network); 15 Oct 2004 20:13:19 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 15 Oct 2004 20:13:19 -0000 Message-Id: <5.2.1.1.0.20041015135819.0412fcb0@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 15 Oct 2004 22:15:08 +0200 To: "'ipsec@ietf.org'" From: Joern Sierwald Subject: Re: [Ipsec] Proposal and Transform Payloads In-Reply-To: <4B399B8DBA86D411BB3500508B9566FF0EF19958@mal-mail-1.dera.g ov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 12:43 15.10.2004 +0100, Case Richard A wrote: >I am looking for clarification of RFC 2408 - I hope you can help! > > > * It is implied but nowhere stated that the Proposal and Transform=20 > numbers must start at one (and not zero) and monotonically increase. Is=20 > this the case? No. You can number them "3, 8, 32000" if you like. And you must be able to accept such a list as valid input. There is a gentlemen's agreement however, that states that you really should use 1,2,3,4... > * Does the order of preference decrease with increasing=20 > Proposal/Transform numbers? i.e. 1 is most preferred, 2 is next most=20 > preferred, etc... No, the order does not mean anything. While there are implementation who=20 treat the list like that, this is not a universally valid logic > * Can you include the same Data Attribute Type multiple times in the=20 > SA Attribute field of a Transform Payload, or do different options need=20 > to be included in separate Transform Payloads? E.g. In the Path 2, Main=20 > Mode, Phase I exchange can I include two data attributes of type 3=20 > (authentication method - let's say for argument 2-DSS & 3-RSA signatures)= =20 > in the same Transform Payload? no, yes. no. > > >Many thanks, > >Richard > >Richard Case >Communication Engineer Cheers, J=F6rn _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 19 03:37:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26549 for ; Tue, 19 Oct 2004 03:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJo6S-0003rB-6R; Tue, 19 Oct 2004 03:08:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJnmd-0000aS-Oi for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 02:47: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 CAA24070 for ; Tue, 19 Oct 2004 02:47:41 -0400 (EDT) From: kent@bbn.com Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJnyg-0005Nj-Tq for ipsec@ietf.org; Tue, 19 Oct 2004 03:00:16 -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 i9J6gEd05956 for ; Tue, 19 Oct 2004 02:42:14 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i9J6iW2q018481 for ; Tue, 19 Oct 2004 02:44:32 -0400 (EDT) Message-Id: <200410190644.i9J6iW2q018481@nutshell.tislabs.com> Received: from unknown(211.147.205.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAACTaybJ; Tue, 19 Oct 04 02:42:30 -0400 To: ipsec@lists.tislabs.com Date: Tue, 19 Oct 2004 14:45:16 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_936E83E7.39D26F0B" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ipsec] 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 This is a multi-part message in MIME format. ------=_NextPart_000_0007_936E83E7.39D26F0B Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Mail failed. For further assistance, please contact! ------=_NextPart_000_0007_936E83E7.39D26F0B Content-Type: text/html; name="readme.zip.htm" Content-Disposition: attachment; filename="readme.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: readme.zip
Virus name: W32/Lovgate.x@MM!zip

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

------=_NextPart_000_0007_936E83E7.39D26F0B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0007_936E83E7.39D26F0B-- From ipsec-bounces@ietf.org Tue Oct 19 04:28:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00756 for ; Tue, 19 Oct 2004 04:28:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJobU-00033U-Uk; Tue, 19 Oct 2004 03:40:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJoRG-0006km-Rc for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 03:29: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 DAA25947 for ; Tue, 19 Oct 2004 03:29:40 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJodD-00063Q-26 for ipsec@ietf.org; Tue, 19 Oct 2004 03:42:15 -0400 Received: from jyothi.intotoinc.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i9J7THT6016010 for ; Tue, 19 Oct 2004 12:59:17 +0530 Message-Id: <5.1.0.14.0.20041014152504.02adcd90@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Oct 2004 13:02:47 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.7 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Ipsec] CHILD SA payloads in AUTH exchange request. X-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="===============1994806134==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1994806134== Content-Type: multipart/alternative; boundary="=====================_617601068==_.ALT" --=====================_617601068==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, When EAP authentication is used, Instead of sending CHILD SA payload, CP request and Traffic selector payloads in first AUTH request message, why cant we send those along with EAP AUTH request payload??? So that we can avoid sending the CHILD SA information in EAP-AUTH failure. IKE messages will be as follows: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] } --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> <-- HDR, SK {AUTH, CP(CFG_REPLY) SAr2, TSi, TSr } Awaiting your valuable replies. Thanks Jyothi --=====================_617601068==_.ALT Content-Type: text/html; charset="us-ascii" Hi all,

When EAP authentication is used,

Instead of sending CHILD SA payload, CP request  and Traffic selector payloads in first AUTH request message, why cant we send those along with EAP AUTH request payload???

So that we can avoid sending the CHILD SA information in EAP-AUTH failure.

IKE messages will be as follows:

       Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni         -->

                                  <--    HDR, SAr1, KEr, Nr, [CERTREQ]

       HDR, SK {IDi, [CERTREQ,] [IDr,]
                }   -->

                                  <--    HDR, SK {IDr, [CERT,] AUTH,
                                                EAP }

       HDR, SK {EAP}              -->

                                  <--    HDR, SK {EAP (success)}

       HDR, SK {AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr}  -->

                        <--    HDR, SK {AUTH, CP(CFG_REPLY) SAr2, TSi, TSr }


Awaiting your valuable replies.

Thanks
Jyothi --=====================_617601068==_.ALT-- --===============1994806134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1994806134==-- From ipsec-bounces@ietf.org Tue Oct 19 05:12:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03737 for ; Tue, 19 Oct 2004 05:12:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJpVw-0001Vp-FI; Tue, 19 Oct 2004 04:38:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJp9P-0007NE-Sg for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 04:15: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 EAA00196 for ; Tue, 19 Oct 2004 04:15:17 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJpLR-00075f-B8 for ipsec@ietf.org; Tue, 19 Oct 2004 04:27:53 -0400 Received: from jyothi.intotoinc.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i9J8F6bm023000 for ; Tue, 19 Oct 2004 13:45:06 +0530 Message-Id: <5.1.0.14.0.20041019130250.02adde50@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Oct 2004 13:48:27 +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-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ipsec] Delete payloads 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 Hi all, I would like to know whether delete payloads can come in any exchange messages or not. If delete payloads received in any message other than informational exchange, Should we ignore the payload or should we drop the message??? Can the informational exchange request/response contain the multiple delete payloads?? Suppose, the peer did not receive a reply for a keep-alive, then can the peer generate an informational exchange with multiple delete payloads (corresponding to IKE SA and CHILD SAs)?? In this case we can avoid sending multiple informational exchange messages. Awaiting your responses. Thanks in advance, Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 19 06:36:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08715 for ; Tue, 19 Oct 2004 06:36:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqZE-00037T-7J; Tue, 19 Oct 2004 05:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqMC-0000UM-IE for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 05:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04749 for ; Tue, 19 Oct 2004 05:32:33 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJqYG-0008Rl-VX for ipsec@ietf.org; Tue, 19 Oct 2004 05:45:10 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i9J9W0a29403; Tue, 19 Oct 2004 11:32:00 +0200 (IST) In-Reply-To: <5.1.0.14.0.20041014152504.02adcd90@172.16.1.10> References: <5.1.0.14.0.20041014152504.02adcd90@172.16.1.10> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Yoav Nir Subject: Re: [Ipsec] CHILD SA payloads in AUTH exchange request. Date: Tue, 19 Oct 2004 11:33:29 +0200 To: Jyothi X-Mailer: Apple Mail (2.618) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I guess the historical reason is that originally the Child SA response=20= (SAr2, CFG_REPLY, Traffic selectors) was supposed to be sent along with=20= the EAP success. This changed relatively recently. I don't think it makes much difference in the real world, because EAP=20 is typically for authenticating clients. The SAi2 is not much secret,=20= the CFG_REQUEST is usually just a request, and the traffic selectors=20 are (myaddress)-(0.0.0.0-255.255.255.255) so there's not much secret=20 information there. I agree that this is a security concern, but not enough so that we need=20= to change the protocol at this stage. On Oct 19, 2004, at 9:32 AM, Jyothi wrote: > Hi all, > > When EAP authentication is used, > > Instead of sending CHILD SA payload, CP request=A0 and Traffic = selector=20 > payloads in first AUTH request message, why cant we send those along=20= > with EAP AUTH request payload??? > > So that we can avoid sending the CHILD SA information in EAP-AUTH=20 > failure. > > IKE messages will be as follows: > > =A0=A0=A0=A0=A0=A0 Initiator=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Responder > =A0=A0=A0=A0=A0 -----------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 ----------- > =A0=A0=A0=A0=A0=A0 HDR, SAi1, KEi, Ni=A0=A0=A0=A0=A0=A0=A0=A0 --> > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=A0=A0=A0 HDR, SAr1, KEr, Nr, [CERTREQ] > > =A0=A0=A0=A0=A0=A0 HDR, SK {IDi, [CERTREQ,] [IDr,] > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }=A0=A0 --> > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=A0=A0=A0 HDR, SK {IDr, [CERT,] AUTH, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = EAP } > > =A0=A0=A0=A0=A0=A0 HDR, SK {EAP}=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= --> > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 <--=A0=A0=A0 HDR, SK {EAP (success)} > > =A0=A0=A0=A0=A0=A0 HDR, SK {AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr}=A0 = --> > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <--=A0=A0=A0 HDR, SK {AUTH, CP(CFG_REPLY) SAr2,=20 > TSi, TSr } > > > Awaiting your valuable replies. > > Thanks > 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 Tue Oct 19 21:42:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13753 for ; Tue, 19 Oct 2004 21:42:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3vx-0004CU-6j; Tue, 19 Oct 2004 20:02:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJtbU-0008QB-ER for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 09:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20305 for ; Tue, 19 Oct 2004 09:00:33 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJtna-00049q-Lb for ipsec@ietf.org; Tue, 19 Oct 2004 09:13:12 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9JD0Rh07961; Tue, 19 Oct 2004 16:00:27 +0300 (EET DST) X-Scanned: Tue, 19 Oct 2004 15:57:34 +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 i9JCvYpl006266; Tue, 19 Oct 2004 15:57:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00FLxeBw; Tue, 19 Oct 2004 15:57:33 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 i9JCvQa27519; Tue, 19 Oct 2004 15:57:27 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 19 Oct 2004 15:56:41 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 19 Oct 2004 15:56:42 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 19 Oct 2004 15:56:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Delete payloads in IKEv2 Date: Tue, 19 Oct 2004 15:56:40 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD47@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] Delete payloads in IKEv2 Thread-Index: AcS1zIhLzk0xbYKOQse63xHkgepgBgAC/xkg To: , X-OriginalArrivalTime: 19 Oct 2004 12:56:40.0326 (UTC) FILETIME=[13867260:01C4B5DB] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable vjyothi@intotoinc.com writes: >=20 > Hi all, >=20 > I would like to know whether delete payloads can come in=20 > any exchange messages or not. >=20 > If delete payloads received in any message other than=20 > informational exchange, Should we ignore the payload=20 > or should we drop the message??? Delete payloads can be sent only in informational exchange. > Can the informational exchange request/response contain the=20 > multiple delete payloads?? Yes (see e.g. Section 3.11). > Suppose, the peer did not receive a reply for a keep-alive,=20 > then can the peer generate an informational exchange with=20 > multiple delete payloads (corresponding to IKE SA and CHILD SAs)??=20 > In this case we can avoid sending multiple informational=20 > exchange messages. If by keep-alive you mean an empty informational exchange, the=20 answer is no: after the peer has given up on retransmissions,=20 it just closes the SAs without sending anything more. (And if you meant NAT keepalives for UDP encapsulation, the other end does not send replies to them.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 19 22:10:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16223 for ; Tue, 19 Oct 2004 22:10:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4AO-0003AU-Kj; Tue, 19 Oct 2004 20:17:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJvn2-0001M2-Ql for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 11:20: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 LAA06266 for ; Tue, 19 Oct 2004 11:20:37 -0400 (EDT) Received: from ouse.qinetiq.com ([192.102.214.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJvz9-0000G5-Ht for ipsec@ietf.org; Tue, 19 Oct 2004 11:33:17 -0400 Received: (qmail 19308 invoked by uid 1011); 19 Oct 2004 15:20:04 -0000 Received: from RACASE@qinetiq.com by ouse.qinetiq.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.75-1. spamassassin: 2.64. Clear:RC:1(10.0.5.21):. Processed in 0.024842 secs); 19 Oct 2004 15:20:04 -0000 Received: from unknown (HELO frome.uncdmz.qinetiq.com) (10.0.5.21) by ouse.qinetiq.com with SMTP; 19 Oct 2004 15:20:03 -0000 Received: from allen.qinetiq.com (Not Verified[10.0.20.10]) by frome.uncdmz.qinetiq.com with NetIQ MailMarshal (v5.5.6.6) id ; Tue, 19 Oct 2004 16:20:02 +0100 Message-ID: <4B399B8DBA86D411BB3500508B9566FF0EF1996F@mal-mail-1.dera.gov.uk> From: Case Richard A To: "'ipsec@ietf.org'" Subject: RE: [Ipsec] Proposal and Transform Payloads Date: Tue, 19 Oct 2004 16:19:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) X-GATEWAY: Unclassified Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thanks to J=F6rn for his comments. I've now read the dictionary definitio= n of "monotonically" and the RFC makes a bit more sense. However, this does raise other questions: >> * Does the order of preference decrease with increasing=20 >> Proposal/Transform numbers? i.e. 1 is most preferred, 2 is next most=20 >> preferred, etc... >No, the order does not mean anything. While there are implementation who= =20 >treat the list like that, >this is not a universally valid logic If this is the case, are there implementations that ignore RFC 2408, sect= ion 4.2 ("The multiple transforms MUST be presented with monotonically increasing numbers in the initiator's preference order.") ? In which case how does the responder know in which order to process the transforms? Presumably by making a note of all Transforms, discarding incompatible options and selecting from the remaining Transforms in its own preference= order? Thanks again, Richard ****************************************************** At 12:43 15.10.2004 +0100, Case Richard A wrote: >I am looking for clarification of RFC 2408 - I hope you can help! > > > * It is implied but nowhere stated that the Proposal and Transform=20 > numbers must start at one (and not zero) and monotonically increase. Is= =20 > this the case? No. You can number them "3, 8, 32000" if you like. And you must be able t= o accept such a list as valid input. There is a gentlemen's agreement however, that states that you really should use 1,2,3,4... > * Does the order of preference decrease with increasing=20 > Proposal/Transform numbers? i.e. 1 is most preferred, 2 is next most=20 > preferred, etc... No, the order does not mean anything. While there are implementation who = treat the list like that, this is not a universally valid logic > * Can you include the same Data Attribute Type multiple times in the= =20 > SA Attribute field of a Transform Payload, or do different options need= =20 > to be included in separate Transform Payloads? E.g. In the Path 2, Main= =20 > Mode, Phase I exchange can I include two data attributes of type 3=20 > (authentication method - let's say for argument 2-DSS & 3-RSA signature= s)=20 > in the same Transform Payload? no, yes. no. > > >Many thanks, > >Richard > >Richard Case >Communication Engineer Cheers, J=F6rn The Information contained in this E-Mail and any subsequent correspondenc= e is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution,= or any action taken or omitted to be taken in reliance on such informatio= n is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 19 22:16:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16705 for ; Tue, 19 Oct 2004 22:16:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4Ca-0003tn-T6; Tue, 19 Oct 2004 20:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJvul-0002AY-G9 for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 11:28:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07014 for ; Tue, 19 Oct 2004 11:28:41 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJw6w-0000YP-DF for ipsec@ietf.org; Tue, 19 Oct 2004 11:41:21 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9JFSMh01948; Tue, 19 Oct 2004 18:28:22 +0300 (EET DST) X-Scanned: Tue, 19 Oct 2004 18:26:44 +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 i9JFQiIE013567; Tue, 19 Oct 2004 18:26:44 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 0087e3Mb; Tue, 19 Oct 2004 18:26:42 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9JFQbS18849; Tue, 19 Oct 2004 18:26:37 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 19 Oct 2004 18:24:41 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 19 Oct 2004 18:24:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] CHILD SA payloads in AUTH exchange request. Date: Tue, 19 Oct 2004 18:24:41 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD4A@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] CHILD SA payloads in AUTH exchange request. Thread-Index: AcS10HVo36s2JHBmTdSYP89yIY54SwAHZKvQ To: , X-OriginalArrivalTime: 19 Oct 2004 15:24:40.0596 (UTC) FILETIME=[C0941D40:01C4B5EF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Having this information available during the EAP exchange may also make it easier to use a RADIUS or Diameter AAA server=20 for e.g. assigning IP addresses. (BTW, these payloads are sent before the responder is authenticated even when EAP is not used.) Best regards, Pasi > -----Original Message----- > From: Yoav Nir > Sent: Tuesday, October 19, 2004 12:33 PM > To: Jyothi > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] CHILD SA payloads in AUTH exchange request. >=20 >=20 > I guess the historical reason is that originally the Child SA=20 > response (SAr2, CFG_REPLY, Traffic selectors) was supposed to=20 > be sent along with the EAP success. This changed relatively=20 > recently. >=20 > I don't think it makes much difference in the real world,=20 > because EAP is typically for authenticating clients. The SAi2=20 > is not much secret, the CFG_REQUEST is usually just a request,=20 > and the traffic selectors are (myaddress)-(0.0.0.0-255.255.255.255)=20 > so there's not much secret information there. >=20 > I agree that this is a security concern, but not enough so=20 > that we need to change the protocol at this stage. >=20 > On Oct 19, 2004, at 9:32 AM, Jyothi wrote: >=20 > > Hi all, > > > > When EAP authentication is used, > > > > Instead of sending CHILD SA payload, CP request=A0and=20 > > Traffic selector payloads in first AUTH request message,=20 > > why cant we send those along with EAP AUTH request=20 > > payload??? > > > > So that we can avoid sending the CHILD SA information in=20 > > EAP-AUTH failure. > > > > IKE messages will be as follows: > > > > =A0=A0=A0=A0=A0=A0 = Initiator=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Responder > > =A0=A0=A0=A0=A0 = -----------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 ----------- > > =A0=A0=A0=A0=A0=A0 HDR, SAi1, KEi, Ni=A0=A0=A0=A0=A0=A0=A0=A0 --> > > > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 <--=A0=A0=A0 HDR, SAr1, KEr,=20 > Nr, [CERTREQ] > > > > =A0=A0=A0=A0=A0=A0 HDR, SK {IDi, [CERTREQ,] [IDr,] > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }=A0=A0 --> > > > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 <--=A0=A0=A0 HDR, SK {IDr,=20 > [CERT,] AUTH, > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 EAP } > > > > =A0=A0=A0=A0=A0=A0 HDR, SK = {EAP}=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --> > > > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 <--=A0=A0=A0 HDR, SK {EAP (success)} > > > > =A0=A0=A0=A0=A0=A0 HDR, SK {AUTH, CP(CFG_REQUEST), SAi2, TSi, = TSr}=A0 --> > > > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = <--=A0=A0=A0 HDR, SK {AUTH, CP(CFG_REPLY) SAr2,=20 > > TSi, TSr } > > > > > > Awaiting your valuable replies. > > > > Thanks > > Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 19 23:34:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21888 for ; Tue, 19 Oct 2004 23:34:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4fh-0007bD-7N; Tue, 19 Oct 2004 20:49:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJyjs-0005jC-OJ for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 14:29:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25986 for ; Tue, 19 Oct 2004 14:29:34 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJyw2-0005xQ-F9 for ipsec@ietf.org; Tue, 19 Oct 2004 14:42:15 -0400 Received: from SriniSony (dhcp-64.intoto.com [10.1.5.64]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i9JIUhRP022258; Tue, 19 Oct 2004 11:30:44 -0700 Message-ID: <01cb01c4b609$8e3e3960$060fa8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: "Tero Kivinen" References: <16741.24908.236436.231881@fireball.kivinen.iki.fi><145001c4acdd$8fffc370$1411a8c0@SriniSony><16742.28077.940436.338326@fireball.kivinen.iki.fi><005f01c4afad$321c1240$1411a8c0@SriniSony> <16747.50231.767484.671819@fireball.kivinen.iki.fi> Subject: Re: [Ipsec] Question about N(COOKIE)andN(INVALID_KE_PAYLOAD)combination Date: Tue, 19 Oct 2004 11:29:21 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I guess this should work. I guess similar logic need to be done on receiver end too as MITM can spoof AUTH request and send to the receiver for the purpose of DoSing the negotiation between security gateways. Srini Intoto Inc. www.intoto.com ----- Original Message ----- From: "Tero Kivinen" To: "Srinivasa Rao Addepalli" Cc: Sent: Tuesday, October 12, 2004 4:47 AM Subject: Re: [Ipsec] Question about N(COOKIE)andN(INVALID_KE_PAYLOAD)combination > Srinivasa Rao Addepalli writes: >> Message ID: I also noticed the statement 'The IKE_SA initial setup messages will >> always be numbered 0 and 1'. I think, these are values if there are no errors >> in leading to SA establishment. I am hoping that, no implementation would reject >> the initial exchanges if the message IDs are not numbered 0 and 1. Actually, in EAP >> case, the message IDs go beyond 1, before it completes AUTH exchange. > > For the EAP case, I think it is quite clear that additional IKE_AUTH > exchanges have new message IDs. For the IKE_SA_INIT, I think the > protocol is simplier if we always assume that the message id is 0, and > the responder does not store any state before it can successfully > reply to the IKE_SA_INIT packet. > >> There are some errors and indications which can be corrected by the IKE >> automatically and there are other type of errors, which require changes by >> the administartor. In the later case, I feel, there is no need to maintain the state. >> For example, NO_PROPOSAL_CHOSEN kind of errors can only be corrected >> by changes to the policy configuration. Any new IKE transaction starts with new >> SPI value and message ID as 0. Here, there is no problem of DoS attack, as the >> attacker has to guess the new SPI and that is difficult for an attacker to do that kind >> of guessing. > > How does now SPIi protect against DoS attacks? If he can see the first > packet having SPIi in it, he can se the new SPIi too. If he cannot see > any traffic he needs to guess the right SPIi in any case and the attack > cost remains about same. > >> In the case of errors, which can be corrected automatically, such as >> INVALID_KE_PAYLOAD, I guess different intrepreations are possible due to >> no explicit descripton in the IKEv2 draft. Whichever is the solution should be >> interoperable and should not lead to simple DoS attacks. You are indicating >> one solution ie if responder chooses SPI value, then the responder is maintaining >> the state and if is is zero, responder does not maintain the state. > > Actually I think it is better that responder never keeps state in that > case, it simply returns error and forgets the exchange. The initiator > will then fix the problem and try again (and he can and should use > same SPIi as the responder have forgotten the previous packet, so there > is no reason why not to use old SPIi, using old SPIi keeps the cookies > valid in case cookie exchange was needed). > >> To protect against DoS attacks, I feel that, if the responder is not maintaing the >> state (it indicates by keeping the responder SPI to 0), then the initiator should >> start the transaction with new initiator SPI value. If the Initiator chooses the same >> SPI value, it becomes easier for an attacker to send error notification, if the attacker >> is intelligently records the previous initiator SPI. > > If the attacker can see the first exchange, he can also see the next > exchange, thus no point of changing SPIi there. I do not think the > change of SPIi will really get you any protection against DoS, but it > will cost you several round trips again, as you need to do cookie > exchange again for each new modification because of the new SPIi. It > also makes the N(COOKIE) notification a special case where the > initiator MUST keep the same SPIi. So easiest way to implement it is > to say that the SPIi stays same as long as the initiator continues > trying, and responder will forget the packet immediately if it > returned error for it (COOKIE, INVALID_KE_PAYLOAD, > INVALID_MAJOR_VERSION etc). > >> * Initiator should send the IKE_SA_INIT exchange with new SPI and >> message ID 0, when the response message contains error indication. > > That will not work for the N(COOKIE) error notification, as it is > already explained in the draft and it mandates that you keep the SPIi > same. > >> * Responder need not generate its SPI, when it sends error notification as part of >> IKE_SA_INIT response. > > I would say responder MUST NOT generate its SPI when it sending error > notifications as part of IKE_SA_INIT response. That would be > consistent with the N(COOKIE) error, i.e. the N(COOKIE) would not be a > special case, but just using same rules as other errors. > > There is no benefit for initiator to change SPIi, or responder to > allocate SPIr in error cases, but for N(COOKIE) error we cannot change > SPIi and we cannot allocate SPIr, so lets keep the processing same for > all error messages including N(COOKIE). > >> With this, combined logic of COOKIE and INVALID_KE_PAYLOAD appear like this >> on the wire. >> >> 1. HDR(A,0,0) SAi1, KEi, Ni ---> >> <--- HDR(A,0,0) N(COOKIE) >> 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> >> <--- HDR(A',X,0) N(INVALID_KE_PAYLOAD) >> 3. HDR(A',0,0) SAi1, KEi(new), Ni ---> >> <--- HDR(A',0,0) N(COOKIE2) >> 4. HDR(A',0,0) N(COOKIE2), SAi1, KEi(new), Ni ---> >> <--- HDR(A',B,0) SAr1, KEr, Nr, [CERTREQ] > > This will add one extra round trip, one extra half-open SA in the > responder end (the one returning INVALID_KE_PAYLOAD), which need to be > timed out and so one. Not very clean solution. > >> Even though above example is given with INVALID_KE_PAYLOAD, it is applicable for >> other messages such as NO_PROPOSAL_CHOSEN. For example, it will appear like this. >> >> 1. HDR(A,0,0) SAi1, KEi, Ni ---> >> <--- HDR(A,0,0) N(COOKIE) >> 2. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> >> <--- HDR(A,X,0) N(NO_PROPOSAL_CHOSEN) > > We cannot accept the NO_PROPOSAL_CHOSEN directly, as it would open DoS > attack by just sending one packet. We need to keep on sending until > the initiator times out. After that we will of course start new > negitation using differnt SPIi, as the old one has already failed. > >> In my opinion, Initiator can even generate new SPI value in transaction 2 ie while sending >> IKE_SA_INIT request with N(COOKIE). With this, even if the attacker >> records INIT_SA_RESPONSE with N(COOKIE)and replays the same, the exchange >> does not succeed. > > If initiator will genreate new SPIi, then responder will send new > N(COOKIE) back again, as the old one does not match (it contains SPIi > in it). The initiator will detect that the replayed IKE_SA_INIT > response do not give any new information how to continue processing > the message, so it will simply continue sending the last packet it has > sent out (having the N(COOKIE)) until the other end responds. If the > attacker send fake N(FAKECOOKIE) notification back before the > responder sends its iwn N(COOKIE) then the initiator will first try > with N(FAKECOOKIE) and when it gets the real N(COOKIE) exchange, it > notices that ok, this changes state again, so it will send new packet > with N(COOKIE) and the responder will only continue with the proper > N(COOKIE) exchange: > > Initiator Attacker Responder > 1. HDR(A,0,0) SAi1, KEi, Ni ---> > 2. <--- HDR(A,0,0) N(FAKECOOKIE) > Responder gets the 1. > packet and replies > 3. <--- HDR(A,0,0) N(COOKIE) > Initiator replies using attackers cookie > 4. HDR(A,0,0) N(FAKECOOKIE), SAi1, KEi, Ni ---> > Responder will either > ignore the message > with wrong cookie, or > reply with similar > message than in 3, > i.e. sends the right > cookie. > Initiator gets the real cookie from responder > notices it is different, and replies with that > 5. HDR(A,0,0) N(COOKIE), SAi1, KEi, Ni ---> > Attacker tries to confuse > things more, and sends new > N(FAKECOOKIE) message > 6. <--- HDR(A,0,0) N(FAKECOOKIE) > Initiator sees again different cookie, and tries > with that. > 7. HDR(A,0,0) N(FAKECOOKIE), SAi1, KEi, Ni ---> > In the mean while the > responder gets the > packet sent in 5, and > notices that the > cookie is valid and > replies with his > message > 8. <--- HDR(A,B,0) SAr1, > KEr, Nr > When initiator gets > packet sent in step 7 > it either ignores it > or replies with > message 3, with right > cookie. > When initiator gets the message 8 > it moves to the IKE_AUTH phase, and after > that it may ignore all IKE_SA_INIT messages. > If it wants to protect from all DoS attacks > it still continues looking for IKE_AUTH messages > and it will move to the IKE_AUTH phase for each > valid IKE_SA_INIT message it gets, and tries to > finish them all. When one of those IKE_AUTH > exchanges finishes, all other half open IKE SAs > with same SPI-i A are deleted. If we continue > example here. > Attacker decides he wants > to cause even more problems > and sends 2 more valid > looking IKE_SA_INIT replies. > 9. <--- HDR(A,X,0) SAr1', KEr', Nr' > 10. <--- HDR(A,Y,0) SAr1'', KEr'', Nr'' > Initiator will process them all, and > start IKE_AUTH for all of them. All of the > packets are encrypted with different key, and MAC'ed > with different key. Each of those require a separate > Diffie-Hellman, as the KEr, KEr', KEr'' received > from other end are different. > 11. HDR(A,B,1) SK1{IDi,AUTH,SAi2,TSi,TSr} ---> > 12. HDR(A,X,1) SK2{IDi,AUTH,SAi2,TSi,TSr} ---> > 13. HDR(A,Y,1) SK3{IDi,AUTH,SAi2,TSi,TSr} ---> > Attacker cannot reply > to any of those as it does > not know how to generate > valid AUTH paylod for reply > packet. He do know > how to generate valid MAC > and how to encrypt the packet, > but he cannot authenticate > himself. > Responder will > ignore unknown SPIr > values X and Y, and > reply to the SPIr B. > 14. <--- HDR(A,B,1) > SK1{IDr, AUTH, > SAr2, TSi, TSr} > Initiator receives the valid packet > authenticating the IKE SA, and deletes > IKE SA (A,X) and (A,Y), at the same time > when it marks (A,B) as finished. > -- > kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 20 00:18:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24998 for ; Wed, 20 Oct 2004 00:18:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4j1-0004WV-T0; Tue, 19 Oct 2004 20:53:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK0Sd-0007yp-09 for ipsec@megatron.ietf.org; Tue, 19 Oct 2004 16:19:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09210 for ; Tue, 19 Oct 2004 16:19:51 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK0en-0001IO-31 for ipsec@ietf.org; Tue, 19 Oct 2004 16:32:34 -0400 Received: from SriniSony (dhcp-39.intoto.com [10.1.5.39]) by intotoinc.com (8.12.5/8.12.5) with SMTP id i9JKL8RP025721; Tue, 19 Oct 2004 13:21:08 -0700 Message-ID: <024b01c4b618$fa6fae70$060fa8c0@SriniSony> From: "Srinivasa Rao Addepalli" To: , "Jyothi" References: <5.1.0.14.0.20041019130250.02adde50@172.16.1.10> Subject: Re: [Ipsec] Delete payloads in IKEv2 Date: Tue, 19 Oct 2004 13:19:44 -0700 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Subject: [Ipsec] Delete payloads in IKEv2 > Hi all, > > I would like to know whether delete payloads can come in any exchange > messages or not. > > If delete payloads received in any message other than informational > exchange, Should we ignore the payload or should we drop the message??? Most of the discussion in the draft in regards to Delete payload is done in the context of INFORMATIONAL exchange. For example, it indicates the recipient of Delete payload in INFORMATIONAL exchange normally replies with its own Delete payloads. I feel that, Delete payloads can only be sent in INFORMATIONAL exchange. If an implementation receives 'Delete payload' as part of any other exchange, I feel it is better for the implementation to ignore this payload and process rest. > > Can the informational exchange request/response contain the multiple delete > payloads?? SRINI> Yes. > > Suppose, the peer did not receive a reply for a keep-alive, then can the > peer generate an informational exchange with multiple delete payloads > (corresponding to IKE SA and CHILD SAs)?? In this case we can avoid sending > multiple informational exchange messages. SRINI> Yes. One information exchange message can have multiple Delete payload. One Delete payload can have multiple SPIs. > > Awaiting your responses. > > Thanks in advance, > > Jyothi > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 20 06:08:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16638 for ; Wed, 20 Oct 2004 06:08:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKBch-0005sg-3j; Wed, 20 Oct 2004 04:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKATa-0007pf-Cr for ipsec@megatron.ietf.org; Wed, 20 Oct 2004 03:01: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 DAA06151 for ; Wed, 20 Oct 2004 03:01:31 -0400 (EDT) Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKAfr-00017o-GO for ipsec@ietf.org; Wed, 20 Oct 2004 03:14:20 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 5DA085B9BB for ; Wed, 20 Oct 2004 10:01:00 +0300 (EEST) Received: from unknown[10.128.128.81]:46785 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.146 Release) with SMTP; Wed, 20 Oct 2004 07:00:58 -0000 Received: (qmail 21390 invoked from network); 20 Oct 2004 07:00:58 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 20 Oct 2004 07:00:58 -0000 Message-Id: <5.2.1.1.0.20041020085459.03d23440@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 20 Oct 2004 09:02:55 +0200 To: Case Richard A , "'ipsec@ietf.org'" From: Joern Sierwald Subject: RE: [Ipsec] Proposal and Transform Payloads In-Reply-To: <4B399B8DBA86D411BB3500508B9566FF0EF1996F@mal-mail-1.dera.g ov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 16:19 19.10.2004 +0100, Case Richard A wrote: >Thanks to J=F6rn for his comments. I've now read the dictionary definition= of >"monotonically" and the RFC makes a bit more sense. The RFC is a victim of poor writing in this case. It should have said "use= =20 1,2,3...". >However, this does raise other questions: > > >> * Does the order of preference decrease with increasing > >> Proposal/Transform numbers? i.e. 1 is most preferred, 2 is next most > >> preferred, etc... > >No, the order does not mean anything. While there are implementation who > >treat the list like that, > >this is not a universally valid logic > >If this is the case, are there implementations that ignore RFC 2408,= section >4.2 ("The multiple transforms MUST be presented with monotonically >increasing numbers in the initiator's preference order.") ? > >In which case how does the responder know in which order to process the >transforms? >Presumably by making a note of all Transforms, discarding incompatible >options and selecting from the remaining Transforms in its own preference >order? > >Thanks again, >Richard The point I was trying to make (but failed) was that while the initiator can put things in a certain order, the initiator has no say at all which one will be picked. The responder will choose. And the thing that matters is the (internal) list in the responder's policy. Most implementations will do exactly what you write in your last sentence. So even if the initiator sends a list (3des, sha-1; 3des, md5) and the responder allows both, it does not mean that the 1st one (3des, sha-1) will be picked. J=F6rn _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 20 11:30:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14709 for ; Wed, 20 Oct 2004 11:30:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHXB-000895-Sy; Wed, 20 Oct 2004 10:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGjq-0005zH-H3 for ipsec@megatron.ietf.org; Wed, 20 Oct 2004 09:42:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03222 for ; Wed, 20 Oct 2004 09:42:43 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKGwA-0000nl-9y for ipsec@ietf.org; Wed, 20 Oct 2004 09:55:35 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i9KDgA2D024607 for ; Wed, 20 Oct 2004 09:42:10 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i9KDg9qn024602; Wed, 20 Oct 2004 09:42:09 -0400 Received: from PKONING.equallogic.com ([172.16.1.105]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Oct 2004 09:42:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16758.27439.646000.210784@gargle.gargle.HOWL> Date: Wed, 20 Oct 2004 09:42:07 -0400 From: Paul Koning To: joern@f-secure.com Subject: RE: [Ipsec] Proposal and Transform Payloads References: <4B399B8DBA86D411BB3500508B9566FF0EF1996F@mal-mail-1.dera.g ov.uk> <5.2.1.1.0.20041020085459.03d23440@dfintra.f-secure.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 20 Oct 2004 13:42:09.0105 (UTC) FILETIME=[986AD410:01C4B6AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >>>>> "Joern" =3D=3D Joern Sierwald writes: Joern> At 16:19 19.10.2004 +0100, Case Richard A wrote: >> Thanks to J=F6rn for his comments. I've now read the dictionary >> definition of "monotonically" and the RFC makes a bit more sense. Joern> The RFC is a victim of poor writing in this case. It should Joern> have said "use 1,2,3...". "monotonically increasing" allows 3,8,2000 (but not 8,3,2000). Certainly 1,2,3 meets the requirement but so do other sequences. Are you saying that implementers should just use 1,2,3? That's fine. Or did you mean that any sequence OTHER than 1,2,3 should be prohibited? That would be a change to the spec. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 20 20:05:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21831 for ; Wed, 20 Oct 2004 20:05:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIKy-0004ub-81; Wed, 20 Oct 2004 11:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHec-0000g8-Mi for ipsec@megatron.ietf.org; Wed, 20 Oct 2004 10:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10622 for ; Wed, 20 Oct 2004 10:41:23 -0400 (EDT) Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHqx-00025o-9G for ipsec@ietf.org; Wed, 20 Oct 2004 10:54:16 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id A2FF45B76B for ; Wed, 20 Oct 2004 17:40:52 +0300 (EEST) Received: from unknown[10.128.128.81]:39313 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.146 Release) with SMTP; Wed, 20 Oct 2004 14:40:50 -0000 Received: (qmail 18523 invoked from network); 20 Oct 2004 14:40:50 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 20 Oct 2004 14:40:50 -0000 Message-Id: <5.2.1.1.0.20041020163001.051a1910@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 20 Oct 2004 16:42:51 +0200 To: ipsec@ietf.org From: Joern Sierwald Subject: RE: [Ipsec] Proposal and Transform Payloads In-Reply-To: <16758.27439.646000.210784@gargle.gargle.HOWL> References: <4B399B8DBA86D411BB3500508B9566FF0EF1996F@mal-mail-1.dera.g ov.uk> <5.2.1.1.0.20041020085459.03d23440@dfintra.f-secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 09:42 20.10.2004 -0400, Paul Koning wrote: > >>>>> "Joern" =3D=3D Joern Sierwald writes: > > Joern> At 16:19 19.10.2004 +0100, Case Richard A wrote: > >> Thanks to J=F6rn for his comments. I've now read the dictionary > >> definition of "monotonically" and the RFC makes a bit more sense. > > Joern> The RFC is a victim of poor writing in this case. It should > Joern> have said "use 1,2,3...". > >"monotonically increasing" allows 3,8,2000 (but not 8,3,2000). >Certainly 1,2,3 meets the requirement but so do other sequences. > >Are you saying that implementers should just use 1,2,3? That's fine. >Or did you mean that any sequence OTHER than 1,2,3 should be >prohibited? That would be a change to the spec. > > paul Ever since I have read the specs I had the feeling that the writer _intended_ to specify numbers increasing by one (like, 1,2,3,4...) but chose the term "monotonically" instead, without really understanding what that meant. I might be wrong. Now, I think everybody should send 1,2,3,4. We (and other people using SSH code, I presume) used to send 0,1,2,3... but icsa kindly asked us to change that some years ago. On the other hand, Tero Kivinen has tested lists with odd numbering (such as 3,8m32000) and some implementations did not quite like them. So, here again the very old guideline: Send out very nice, well-mannered data but expect the worst in your input buffer. J=F6rn _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 21 21:55:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28419 for ; Thu, 21 Oct 2004 21:55:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoHL-0002IR-FS; Thu, 21 Oct 2004 21:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKn2W-0002ax-1q for ipsec@megatron.ietf.org; Thu, 21 Oct 2004 20:12: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 UAA08786 for ; Thu, 21 Oct 2004 20:12:13 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnFE-0004y7-1x for ipsec@ietf.org; Thu, 21 Oct 2004 20:25:24 -0400 Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9M0C7b3041879 for ; Thu, 21 Oct 2004 17:12:07 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 21 Oct 2004 17:12:11 -0700 To: IPsec WG From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ipsec] IKE v1 algorithms draft -01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. I revised my -00 draft based on comments from the mailing list. If folks in the IKEv1 world would review this, that would be great. We might even get this through before IKEv2... ===== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Algorithms for Internet Key Exchange version 1 (IKEv1) Author(s) : P. Hoffman Filename : draft-hoffman-ikev1-algorithms-01.txt Pages : 5 Date : 2004-10-20 The required and suggested algorithms in the original IKEv1 specification does not reflect the current reality of IPsec market. It requires allowing weak security and suggests algorithms that are thinly implemented. This document updates the original specification and is intended for all IKEv1 implementations deployed today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-ikev1-algorithms-01.txt ===== --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 22 02:09:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26478 for ; Fri, 22 Oct 2004 02:09:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsZd-0006Nf-Hh; Fri, 22 Oct 2004 02:06:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsXn-0004mT-MF for ipsec@megatron.ietf.org; Fri, 22 Oct 2004 02:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22171 for ; Fri, 22 Oct 2004 02:04:54 -0400 (EDT) Received: from cp.64translator.com ([202.214.123.2] helo=senegal.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKskW-0006l8-VS for ipsec@ietf.org; Fri, 22 Oct 2004 02:18:05 -0400 Received: from localhost (localhost [IPv6:::1]) by senegal.64translator.com (8.12.11/8.12.11) with SMTP id i9M64HDS000634 for ; Fri, 22 Oct 2004 15:04:17 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Date: Fri, 22 Oct 2004 15:04:17 +0900 From: Nobumichi Ozoe To: ipsec@ietf.org Message-Id: <20041022150417.7dda2f10.Nobumichi.Ozoe@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [Ipsec] Is always padding required for the payload encrypted in IKE? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, I have question about the padding in IKE. Q1. When the encrypted payload is the size of a byte boundary exactly, is it necessary to surely attach the padding? e.g Encryption algorithm: 3DES-CBC Hash algorithm: SHA The size of the data encrypted is 48 bytes. There are two part in RFC2409 about padding, first says "always be padding", second says "should be padded". Page 15, last paragraph Encrypted payloads are padded up to the nearest block size. All padding bytes, except for the last one, contain 0x00. The last byte of the padding contains the number of the padding bytes used, excluding the last one. Note that this means there will always be padding. Page 38, line 19 Each message should be padded up to the nearest block size using bytes containing 0x00. The message length in the header MUST include the length of the pad since this reflects the size of the ciphertext. Q2. When the encrypted message which does not contain the padding is received, should receiver receive it? Q3. If so, how should receiver process? Please let me know RFC which is consulted. Regards, --- Nobumichi Ozoe TAHI Project _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 22 04:33:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12188 for ; Fri, 22 Oct 2004 04:33:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKupa-0000QC-H4; Fri, 22 Oct 2004 04:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKufq-00060s-5j for ipsec@megatron.ietf.org; Fri, 22 Oct 2004 04:21: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 EAA11648 for ; Fri, 22 Oct 2004 04:21:19 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKusa-0000o2-7Q for ipsec@ietf.org; Fri, 22 Oct 2004 04:34:33 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9M8LHo19513; Fri, 22 Oct 2004 11:21:17 +0300 (EET DST) X-Scanned: Fri, 22 Oct 2004 11:20:04 +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 i9M8K4kC000577; Fri, 22 Oct 2004 11:20:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00LXL0Jd; Fri, 22 Oct 2004 11:20:03 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 i9M8K1a11461; Fri, 22 Oct 2004 11:20:01 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 22 Oct 2004 11:19:55 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 22 Oct 2004 11:19:55 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 22 Oct 2004 11:19:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Is always padding required for the payload encrypted in IKE? Date: Fri, 22 Oct 2004 11:19:53 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD55@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] Is always padding required for the payload encrypted in IKE? Thread-Index: AcS4A1jLEBCrZS2+RbGmqRhTQHr1ZgACKCSg To: , X-OriginalArrivalTime: 22 Oct 2004 08:19:54.0256 (UTC) FILETIME=[E8C68100:01C4B80F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, It looks like the text on Page 15 is talking about encrypting=20 some individual payloads in Phase 1 "revised mode of public key encryption" messages ("Ke_i" and "KE_r"),=20 while Page 38 is about encrypting the whole ISAKMP message ("HDR*"). Thus, I don't think there's any conflict between the "always be=20 padding" and "should be padded", since they refer to different cases. Best regards, Pasi > -----Original Message----- > From: Nobumichi Ozoe > Sent: Friday, October 22, 2004 9:04 AM > To: ipsec@ietf.org > Subject: [Ipsec] Is always padding required for the payload=20 > encrypted in IKE? > >=20 > Hello, >=20 > I have question about the padding in IKE. >=20 > Q1. When the encrypted payload is the size of a byte boundary=20 > exactly, is it necessary to surely attach the padding? >=20 > e.g > Encryption algorithm: 3DES-CBC > Hash algorithm: SHA > The size of the data encrypted is 48 bytes. >=20 > There are two part in RFC2409 about padding, first says=20 > "always be padding", second says "should be padded". >=20 > Page 15, last paragraph > Encrypted payloads are padded up to the nearest block size.=20 > All padding bytes, except for the last one, contain 0x00. The > last byte of the padding contains the number of the padding > bytes used, excluding the last one. Note that this means there=20 > will always be padding. >=20 > Page 38, line 19 > Each message > should be padded up to the nearest block size using bytes=20 > containing 0x00. The message length in the header MUST=20 > include the length of the pad since this reflects the=20 > size of the ciphertext. >=20 > Q2. When the encrypted message which does not contain the=20 > padding is received, should receiver receive it? >=20 > Q3. If so, how should receiver process? Please let me know=20 > RFC which is consulted. >=20 > Regards, >=20 > --- > Nobumichi Ozoe > TAHI Project _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 22 05:43:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15892 for ; Fri, 22 Oct 2004 05:43:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvtN-0007RL-SY; Fri, 22 Oct 2004 05:39:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvkm-0004XT-Et for ipsec@megatron.ietf.org; Fri, 22 Oct 2004 05:30: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 FAA15225 for ; Fri, 22 Oct 2004 05:30:29 -0400 (EDT) Received: from cp.64translator.com ([202.214.123.2] helo=senegal.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKvxX-0001sK-2V for ipsec@ietf.org; Fri, 22 Oct 2004 05:43:44 -0400 Received: from localhost (localhost [IPv6:::1]) by senegal.64translator.com (8.12.11/8.12.11) with SMTP id i9M9Tnwp000863; Fri, 22 Oct 2004 18:29:49 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Date: Fri, 22 Oct 2004 18:29:49 +0900 From: Nobumichi Ozoe To: Subject: Re: [Ipsec] Is always padding required for the payload encrypted in IKE? Message-Id: <20041022182949.27629a5b.Nobumichi.Ozoe@jp.yokogawa.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD55@esebe056.ntc.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD16FD55@esebe056.ntc.nokia.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Thank you for your reply. On Fri, 22 Oct 2004 11:19:53 +0300 wrote: > > Hi, > > It looks like the text on Page 15 is talking about encrypting > some individual payloads in Phase 1 "revised mode of public key > encryption" messages ("Ke_i" and "KE_r"), > while Page 38 is about encrypting the whole ISAKMP message ("HDR*"). > > Thus, I don't think there's any conflict between the "always be > padding" and "should be padded", since they refer to different > cases. Ok. Then, the receiver should receive the encrypted isakmp message without the padding, is right? > Best regards, > Pasi > > > -----Original Message----- > > From: Nobumichi Ozoe > > Sent: Friday, October 22, 2004 9:04 AM > > To: ipsec@ietf.org > > Subject: [Ipsec] Is always padding required for the payload > > encrypted in IKE? > > > > > > Hello, > > > > I have question about the padding in IKE. > > > > Q1. When the encrypted payload is the size of a byte boundary > > exactly, is it necessary to surely attach the padding? > > > > e.g > > Encryption algorithm: 3DES-CBC > > Hash algorithm: SHA > > The size of the data encrypted is 48 bytes. > > > > There are two part in RFC2409 about padding, first says > > "always be padding", second says "should be padded". > > > > Page 15, last paragraph > > Encrypted payloads are padded up to the nearest block size. > > All padding bytes, except for the last one, contain 0x00. The > > last byte of the padding contains the number of the padding > > bytes used, excluding the last one. Note that this means there > > will always be padding. > > > > Page 38, line 19 > > Each message > > should be padded up to the nearest block size using bytes > > containing 0x00. The message length in the header MUST > > include the length of the pad since this reflects the > > size of the ciphertext. > > > > Q2. When the encrypted message which does not contain the > > padding is received, should receiver receive it? > > > > Q3. If so, how should receiver process? Please let me know > > RFC which is consulted. > > > > Regards, > > > > --- > > Nobumichi Ozoe > > TAHI Project > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 22 16:01:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05194 for ; Fri, 22 Oct 2004 16:01:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5XA-0008Am-8f; Fri, 22 Oct 2004 15:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5MX-0001y6-3P for ipsec@megatron.ietf.org; Fri, 22 Oct 2004 15:46:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03715 for ; Fri, 22 Oct 2004 15:46:05 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5ZM-0005D5-86 for ipsec@ietf.org; Fri, 22 Oct 2004 15:59:25 -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 i9MJeVd20456 for ; Fri, 22 Oct 2004 15:40:32 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i9MJTfDs012651 for ; Fri, 22 Oct 2004 15:29:41 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAACoaaTy; Fri, 22 Oct 04 15:29:38 -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 i9MJWfjf006749; Fri, 22 Oct 2004 15:32:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20041004135422.02dcf6b0@email> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> Date: Fri, 22 Oct 2004 15:31:55 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt 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: 67c1ea29f88502ef6a32ccec927970f0 Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Mark, Karen and I were reviewing all the comments we received during the WG last call, making final change to 2401bis. Most of your comments were easy to address, but there were some that require further discussion, or which we feel do not merit the changes you suggest: >Sect 5 first paragraph: > >"But, if the SPD entries are first decorrelated, then the resulting >entries can safely be cached, and each cached entry will map to >exactly one SA, or indicate that matching traffic should be bypassed >or discarded, appropriately. (Note: The original SPD entry might >result in multiple SAs, e.g., because of PFP.)" > >As the text here points out, multiple SAs might be created pursuant >to one SPD entry. But it seems like a bit of a leap from that to >saying that each cached SPD entry maps to one SA. It doesn't even >seem correct, unless the "SPD cache" *by definition of the model* >contains entries that map to one SA each. If that is the case it >should be so stated; otherwise the statement about each cached SPD >entry mapping to one SA should be removed. As far as I can see, >nothing is gained by requiring the SPD cache to be so fine-grained. in general, an entry in the SPD cache points to exactly one SA. this is what one would expect because the purpose of the cache is to speed up the mapping of outbound packets to SAs. there are exceptions, however, and so we will revise the text. exceptions arise when one uses multiple SAs to carry traffic of different priorities (e.g., as indicated by distinct DSCP values) but with the same selectors, on different SAs. >In sect. 5.1 item 4: > >" 4. The packet is passed to the outbound forwarding function >(operating outside of the IPsec implementation), to select the >interface to which the packet will be directed. This function may >cause the packet to be passed back across the IPsec boundary, for >additional IPsec processing, e.g., in support of nested SAs. If so, >there MUST be an entry in SPD-I database that permits inbound >bypassing of the packet, otherwise the packet will be discarded." > >I don't understand why the last 2 sentences are there. Let's look >at the case of an overlay network, which I presume is one of the >applications that might cause iterated application of IPsec. After >once applying IPsec we have, say, an ESP packet. We do a forwarding >lookup on the dest address of the ESP packet and that forwarding >lookup selects another (or the same) SPD-O/SPD-S, which the packet >is then evaluated against. Where and why does the SPD-I bypass rule >come into play in such a scenario? Where is the packet "passed back >across the IPsec boundary"? I think perhaps there is more to the >model you have in mind here then I am picking up from the text. Once a packet has crossed the IPsec boundary, it cannot be processed via IPsec again, unless it is bypassed, i.e., lopped. this is true in both directions, inbound or outbound. If one requires multiple passes through IPsec to protect a packet, then one must have entries in the SPD-O/I caches to allow such bypassing, as illustrated in Appendix E. >In sect. 7.4 (BYPASS/DISCARD traffic) it says "An implementation >MUST support stateful fragment checking to accommodate BYPASS >traffic for which a non-trivial port range is specified." This >seems to mandate that an implementation support the type of stateful >fragment checking that is made a MAY in 7.3. > >I propose that this statement be changed to include the alternative >of dropping the non-initial fragments (which should be the normal >behavior *anyway* if there is no applicable SPD policy with port >selectors of ANY or OPAQUE). So I would change the above-quoted >sentence to: > > "An implementation MAY BYPASS non-initial fragments pursuant to >an SPD policy entry with a non-trivial port range if stateful >fragment checking is performed to verify the applicable ports for >those fragments." Yes, 7.3 is a MAY, but that's for protected traffic, not for BYPASS traffic. The debate over fragment handling for IPsec-protected traffic spilled over into BYPASS traffic as well, as documented in Appendix D. I don't recall messages that suggest the WG decided to drop the requirement to support fragment reassembly for BYPASS fragments. If you can point me to the relevant messages, then we will change the text as you suggest. >In sect 8.2.1 (propagation of PMTU), it says that once it has >"learned" a new PMTU, the IPsec implementation should wait for >outbound traffic for the SA and "When such traffic arrives, if the >traffic would exceed the updated PMTU value the traffic MUST be >discarded and an appropriate ICMP PMTU message sent." > >I think that is the correct behavior *if* the packet had DF set, but >if it does not then the IPsec implementation should either fragment >then encrypt or encrypt then fragment, per its configuration. Tbe processing described above is correct for IPv4 when the DF bit is set, as you noted. It also is appropriate for IPv6, because we can't fragment on the plaintext side for v6. maybe we could fragment on the ciphertext side, but that is still not in the spirit of v6, since we are an intermediate system performing fragmentation. The question is very poor performance that results for v4 or v6 if we fragment. How about compromise: for v6 we send the PMTU and drop the packet, as now described; for v4 we send the PMTU message, but still pass the packet, fragmenting on either side as configured. >Appendix D has not been updated to align with what was eventually >decided, and so may lead to confusion. Perhaps it should just be >dropped? We were explicitly asked to preserve the analysis that motivated the final text in 2401bis, hence the appendix in question. The Appendix presents arguments for different approaches, and ends with the observation that we settled for one MUST and two MAYs. other than the question about fragment reassembly for BYPASS traffic, what parts of it do you feel are no longer consistent with the final text? Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 25 05:02:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02580 for ; Mon, 25 Oct 2004 05:02:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0em-0005F8-Bw; Mon, 25 Oct 2004 04:56:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0dW-0004jj-Bz for ipsec@megatron.ietf.org; Mon, 25 Oct 2004 04:55:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02200 for ; Mon, 25 Oct 2004 04:55:27 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM0qv-0000t6-3X for ipsec@ietf.org; Mon, 25 Oct 2004 05:09:22 -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 i9P8stjf018297; Mon, 25 Oct 2004 04:54:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 25 Oct 2004 04:57:14 -0400 To: ipsec@ietf.org From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.2 (/) X-Scan-Signature: 88e8087d1b20b7fe0211e68acd23c714 Cc: kseo@bbn.com Subject: [Ipsec] IPsec 2401bis -- 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: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Folks, We just submitted a new draft of 2401bis to the IETF publications folks. It has the changes listed below (plus a few typo fixes that I didn't list). Steve Kent and I discussed the various issues that have been raised and how to address them, but I was still doing some of the edits late tonight. So he didn't get a chance to review the changed text before I sent it in. So, once again, any errors are mine. Note: a. The ASN.1 needs to be revised to reflect the addition of local and remote tunnel addresses. I didn't get a chance to check on this with the local ASN.1 guru. b. There are several items that Mark and Francis brought up for which we need further clarification/discussion. We have sent (or will send) email on these. Please let us know if you have any questions. Thank you, Karen ============================================================================== 1. Lars Volker 5.1 Outbound IP Traffic Processing (protected-to-unprotected), Figure 2 and 5.2 Processing Inbound IP Traffic (unprotected-to-protected), Figure 3 -- Changed the text in the right side box: From: "PROTECT (AH/ESP)" To: "PROCESS (AH/ESP)" ============================================================================== 2. Matthew Condell 4.4.1 The Security Policy Database (SPD), Section on "Decorrelation", paragraph 2 -- Added reference for decorrelation "[CoSa04]" and Informative (References) -- Added a reference for decorrelation [CoSa04] Condell, M., and Sanchez, L. On the Deterministic Enforcement of Un-ordered Security Policies", BBN Technical Memo 1346, March 2004 ============================================================================== 3. Ted Tso (and Mark Duffy) 4.1 Definition and Scope, paragraph 4 -- modified use of curly brackets to be consistent by changing: From: 1. Search the SAD for a match on the combination of SPI, destination address, and source address}. To: 1. Search the SAD for a match on the combination of SPI, destination address, and source address. and also changing From: 3. Search the SAD for a match on only {SPI}.... To: 3. Search the SAD for a match on only SPI ============================================================================== 4. Ted Tso (and Mark Duffy) 4.1 Definition and Scope, paragraph 7 -- removed hyphen from "-support" From: Therefore a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to -support.... To: Therefore a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support..... ============================================================================== 5. Ted Tso 4.4 Major IPsec Databases -- added period at end of last sentence of last paragraph ============================================================================== 6. Joe Touch 4.1 Definition and Scope, paragraph 10 -- Added a reference for "Use of IPsec Transport Mode for Dynamic Routing" From: A transport mode SA is a security association typically employed between a pair of hosts to provide end-to-end security services. When security is desired between two intermediate systems along a path (vs. end-to-end use of IPsec), transport mode MAY be used between security gateways or between a security gateway and a host. In the latter case, transport mode may be used to support in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00] over transport mode SAs. To: A transport mode SA is a security association typically employed between a pair of hosts to provide end-to-end security services. When security is desired between two intermediate systems along a path (vs. end-to-end use of IPsec), transport mode MAY be used between security gateways or between a security gateway and a host. In the latter case, transport mode may be used to support in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00] or Dynamic routing [ToEgWa04]) over transport mode SAs. Informative ( References) -- Added the following reference [ToEgWa04] Touch, J., Eggert, L., Wang, Y., "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004. ============================================================================== 7. Joe Touch Fragments carried via SAs pose problems for access control checks. In the situation where a transport mode SA is using IP-in-IP tunneling, IPsec does not see the inner IP header. Made the changes shown below Section D.1 Transport Mode and Fragments, paragraph 4 -- made the two changes in square brackets []. In 2401bis, we have explicitly said that it is OK to use transport mode in cases where the IPsec implementation is not the ultimate destination, e.g., between two SGs. In principle, this creates a new opportunity for outbound, plaintext fragments to be mapped to a transport mode SA for IPsec processing. However, in these new contexts in which a transport mode SA is now approved for use, it seems likely that we can continue to prohibit transmission of fragments, as seen by IPsec, [inserted "i.e., packets that have an "outer header" with a non-zero fragment offset field"]. For example, in an IP overlay network, packets being sent over transport mode SAs are IP-in-IP tunneled and thus have the necessary inner header to accommodate fragmentation prior to IPsec processing. When carried via a transport mode SA, IPsec would not examine the inner IP header for such traffic, and thus would not consider the packet to be a fragment. [deleted last sentence] Section 4.1 Definition and Scope, paragraph 13, which starts "Several concerns motivate the use of tunnel mode....": added the following 2 sentences: (Use of an IP-in-IP tunnel in conjunction with transport mode can also address these fragmentation issues. However, this configuration limits the ability of IPsec to enforce access control policies on traffic.) ============================================================================== 8. Francis Dupont 4.4.1.2 Structure of an SPD entry -- Added fields for local and remote tunnel addresses. (These fields were already present in the SAD.) From: - IPsec mode -- tunnel or transport To: - IPsec mode -- tunnel or transport - (if tunnel mode) local tunnel address -- For a non-mobile host, if there is just one interface, this is straight- forward and if there are multiple interfaces, this must be statically configured. For a mobile host, the specifi- cation of the local address is handled externally to IPsec. - (if tunnel mode) remote tunnel address -- There is no standard way to determine this. See 4.5.3 "Locating a Security Gateway". Did not have a chance to UPDATE the ASN.1 -- need to consult with Charlie Gardiner. ============================================================================== 9. Francis Dupont & Mohan Parthasarathy Clarified issues re: SAD acting as a cache for the SPD with regard to inbound IPsec-protected traffic, keeping the SAD up-to-date if the SPD changes 4.4.1 The Security Policy Database (SPD), section on "Handling Changes to the SPD while the System is Running" -- changed the MAY to SHOULD: From: If a change is made to the SPD while the system is running, a check SHOULD be made of the effect of this change on extant SAs. An implementation MAY choose to check the impact of an SPD change on extant SAs and to provide a user/administrator with a mechanism for configuring what actions to take, e.g., delete an affected SA, allow an affected SA to continue unchanged, etc. To: If a change is made to the SPD while the system is running, a check SHOULD be made of the effect of this change on extant SAs. An implementation SHOULD check the impact of an SPD change on extant SAs and SHOULD provide a user/administrator with a mechanism for configuring what actions to take, e.g., delete an affected SA, allow an affected SA to continue unchanged, etc. 4.4.1 The Security Policy Database (SPD), section on "How To Derive the Values for an SAD entry" -- Added a sentence From: For each selector in an SPD entry, the entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.2) entry from those in the SPD and the packet. The goal is to allow an SAD entry and an SPD cache entry to be created based on specific selector values from the packet, or from the matching SPD entry. To: For each selector in an SPD entry, the entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.2) entry from those in the SPD and the packet. The goal is to allow an SAD entry and an SPD cache entry to be created based on specific selector values from the packet, or from the matching SPD entry. For outbound traffic, there are SPD-S cache entries and SPD-O cache entries. For inbound traffic, there are SPD-I cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (See Figure 3 in Section 5.2). 4.4.2 Security Association Database (SAD), last paragraph just before Section 4.4.2.1 -- modified as follows: From: For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST contain the value or values negotiated at the time the SA was created. For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the selector values negotiated for the SA.... To: For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST be initially populated with the value or values negotiated at the time the SA was created. (See Section 4.4.1, paragraph on "Handling Changes to the SPD while the System is Running" for guidance on the effect of SPD changes on extant SAs.) For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the selector values negotiated for the SA. Thus, the SAD acts as a cache for checking the selectors of inbound traffic arriving on SAs... 5. IP Traffic Processing, paragraph 1 -- inserted a sentence: From: As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded. To simplify processing, and to allow for very fast SA lookups (for SG/BITS/BITW), this document introduces the notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), and a cache for inbound, non-IPsec-protected traffic (SPD-I)..... To: As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded. To simplify processing, and to allow for very fast SA lookups (for SG/BITS/BITW), this document introduces the notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As noted earlier, the SAD acts as a cache for checking the selectors of inbound IPsec-protected traffic arriving on SAs.).... ============================================================================== 10. Francis Dupont & Mohan Parthasarathy 4.4.1 The Security Policy Database (SPD), section on "Decorrelation" -- clarified that decorrelation is not required. From: The processing model described in this document assumes the ability to decorrelate overlapping SPD entries to permit caching, which enables more efficient processing of outbound traffic in security gateways and BITS/BITW implementations. Native host implementations have an implicit form of caching available, due to the use of, for example, socket interfaces for applications, and thus there is no requirement to be able to decorrelate SPD entries in these implementations.) Note: Decorrelation is a means of improving performance and simplifying the processing description; it is not a requirement for a compliant implementation. In this section, unless otherwise noted, the use of "SPD" refers to the body of policy information in both ordered or decorrelated (unordered) state. To: The processing model described in this document assumes the ability to decorrelate overlapping SPD entries to permit caching, which enables more efficient processing of outbound traffic in security gateways and BITS/BITW implementations. Decorrelation [CoSa04] is only a means of improving performance and simplifying the processing description. This RFC does not require a compliant implementation to make use of decorrelation. For example, native host implementations typically make use of caching implicitly because they bind SAs to socket interfaces, and thus there is no requirement to be able to decorrelate SPD entries in these implementations.) Note: Unless otherwise qualified, the use of "SPD" refers to the body of policy information in both ordered or decorrelated (unordered) state. ============================================================================== 11. Francis Dupont 4.1 Definition and Scope -- moved "anycast" case from paragraph 2 (unicast) to paragraph 3 (multicast): From (paragraph 2 and 3): For an SA used to carry unicast (or anycast) traffic,.... In many secure multicast architectures,.... To (paragraph 2 and 3): For an SA used to carry unicast traffic,.... In many secure multicast (or anycast) architectures,.... ============================================================================== 12. Francis Dupont 4.1 Definition and Scope, SAD lookup -- removed "ESP" from steps 1, 2 and 3. From: 1. Search the SAD for a match on the combination of SPI, destination address, and source address}. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2. 2. Search the SAD for a match on both SPI and destination address. If the SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3. 3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, and on both SPI and protocol otherwise. If an SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event. To: 1. Search the SAD for a match on the combination of SPI, destination address, and source address}. If an SAD entry matches, then process the inbound packet with that matching SAD entry. Otherwise, proceed to step 2. 2. Search the SAD for a match on both SPI and destination address. If the SAD entry matches then process the inbound packet with that matching SAD entry. Otherwise, proceed to step 3. 3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, and on both SPI and protocol otherwise. If an SAD entry matches then process the inbound packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event. ============================================================================== 13. Francis Dupont 7. Handling Fragments (on the protected side of the IPsec boundary), paragraph 3 -- Made use of "non-initial" fragment consistent with Section 4.4. Changed: From: Note: The term "non-initial fragment" is used here to indicate a fragment that does not contain all the selector values that may be needed for access control. As observed in Section 4.4.1, depending on the Next Layer Protocol, in addition to Ports, the ICMP message type/code or Mobility Header type could be missing from non-initial fragments. Also, for IPv6, even an initial fragment might NOT contain the Next Layer Protocol or Ports (or ICMP message type/code, or Mobility Header type) depending on the kind and number of extension headers present. To: Note: The term "non-initial fragment" is used here to indicate a fragment that does not contain all the selector values that may be needed for access control. As observed in Section 4.4.1, depending on the Next Layer Protocol, in addition to Ports, the ICMP message type/code or Mobility Header type could be missing from non-initial fragments. Also, for IPv6, even the first fragment might NOT contain the Next Layer Protocol or Ports (or IPsec message type/code, or Mobility Header type) depending on the kind and number of extension headers present. ============================================================================== 14. Francis Dupont 5.1 Outbound IP Traffic Processing (protected-to-unprotected), Step 3b, 7th sentence -- There was a "may" following a "MAY". Changed the sentence: From: (A packet that triggers an SPD lookup MAY be discarded by the implementation, or it may be processed against the newly created cache entry, if one is created.) To: (A packet that triggers an SPD lookup MAY be discarded by the implementation, or it MAY be processed against the newly created cache entry, if one is created.) ============================================================================== 15. Francis Dupont 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode -- Added note for the table entry for "flow label" From: "copied or configured" To: "copied or configured (8)" Added note (8) 8. See [RaCoCaDe04] -- Copying is acceptable only for end systems, not SGs. If an SG copied flow labels from the inner header to the outer header, collisions might result. Should we add flow label to SPD and SAD (when configured for a tunnel)? ============================================================================== 16. Francis Dupont Informational (References) -- updated reference for Mobip From: [Mobip] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", Work in Progress, June 2003 To: [Mobip] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004 ============================================================================== 17. Mark Duffy 3.1 What IPsec Does, 2nd paragraph, 4th sentence -- corrected next to last word from "unprotected" to "protected". From: In this document, the term "inbound" refers to traffic entering an IPsec implementation via the unprotected interface or emitted by the implementation on the unprotected side of the boundary and directed towards the unprotected interface. To: In this document, the term "inbound" refers to traffic entering an IPsec implementation via the unprotected interface or emitted by the implementation on the unprotected side of the boundary and directed towards the protected interface. ============================================================================== 18. Mark Duffy 4.1 Definition and Scope, paragraph 10, sentence 3 -- clarified to what case the sentence was referring. Changed From: In the latter case, transport mode may be used to support in-IP tunneling... To: In the case where transport mode is used between security gateways or between a security gateway and a host, transport mode may be used to support in-IP tunneling... ============================================================================== 19. Mark Duffy 4.4.1 The Security Policy Database (SPD), paragraph on "SPD-S, SPD-I, SPD-O", sentence 9 -- removed "the same rule applies here" which appears to be old text that once meant something, but now is just confusing. From: Since the SPD-I is just a part of the SPD, the same rule applies here, i.e., if a packet that is looked up in the SPD-I cannot be matched to an entry there, then the packet MUST be discarded. To: Since the SPD-I is just a part of the SPD, if a packet that is looked up in the SPD-I cannot be matched to an entry there, then the packet MUST be discarded. ============================================================================== 20. Mark Duffy 4.4.1 The Security Policy Database (SPD), paragraph on SPD-S, SPD-I, SPD-O -- added a sentence at the end. In an ordered, non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O are interleaved. So there is one look up in the SPD. ============================================================================== 21. Mark Duffy 4.4.1.1 Selectors, "Next Layer Protocol", sentence 4 -- Changed IP to IPv6. From: To simplify locating the Next Layer Protocol, there SHOULD be a mechanism for configuring which IP extension headers to skip. To: To simplify locating the Next Layer Protocol, there SHOULD be a mechanism for configuring which IPv6 extension headers to skip. ============================================================================== 22. Mark Duffy 4.4.1.1 Selectors, "Mobility Header, sentence 4 -- Clarified that the directions re:placement of values applied to IKE. From: The IPv6 mobility header message type (MH type) is placed in the most significant eight bits of the 16 bit local "port" selector. To: For IKE, the IPv6 mobility header message type (MH type) is placed in the most significant eight bits of the 16 bit local "port" selector. 4.4.1.1 Selectors, "ICMP", sentence 4 -- same clarification as above. From: The message type is placed in the most significant 8 bits of the 16-bit selector and the code is placed in the least significant 8 bits. To: For IKE, the message type is placed in the most significant 8 bits of the 16-bit selector and the code is placed in the least significant 8 bits. ============================================================================== 23. Mark Duffy 4.4.1.3 More re: Fields Associated with Next Layer Protocols -- clarified where the values were being set: From: A. If a Next Layer Protocol has no "port" selectors, then the Local and Remote "port" selectors are set to OPAQUE, e.g., To: A. If a Next Layer Protocol has no "port" selectors, then the Local and Remote "port" selectors are set to OPAQUE in the relevant SPD entry, e.g., From: B. If a Next Layer Protocol has only one selector, e.g., Mobility Header type, then that field is placed in the Local "port" selector, and the Remote "port" selector is set to OPAQUE, e.g., To: B. If a Next Layer Protocol has only one selector, e.g., Mobility Header type, then that field is placed in the Local "port" selector in the relevant SPD entry, and the Remote "port" selector is set to OPAQUE in the relevant SPD entry, e.g., ============================================================================== 24. Mark Duffy Name isn't really a selector like local or remote address. 4.4.1.1 Selectors -- modified Name section to indicate it's not really a selector From: - Name: A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways: To: - Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways: 4.4.1.2 Structure of an SPD entry From: o Name -- a list of IDs. This selector is optional. To: o Name -- a list of IDs. This quasi-selector is optional. ============================================================================== 25. Mark Duffy 4.4.2.1 Data Items in the SAD -- Added Bypass DF bit and Bypass DSCP to SAD o Bypass DF bit (T/F) - applicable to tunnel mode SAs o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values - applicable to tunnel mode SAs ============================================================================== 26. Mark Duffy 5.1.1 Handling an Outbound Packet That Must Be Discarded -- generalized the first case. From: b1. The IPsec system\was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange is administratively prohibited from communicating with the initiator. To: b1. The IPsec system successfully reached the remote peer but was unable to negotiate the SA required by the SPD entry matching the packet, e.g., because the remote peer is administratively prohibited from communicating with the initiator, or the initiating peer was unable to authenticate itself to the remote peer, or the remote peer was unable to authenticate itself to the initiating peer, or no suitable SA could be negotiated with the remote peer, etc.. ============================================================================== 27. Mark Duffy 5.1.2 Header Construction for Tunnel Mode, 4th bullet -- clarified that "DS field" is "outer DS field." From: o IPsec offers certain controls to a security administrator to manage covert channels (which would not normally be a concern for tunneling) and to ensure that the receiver examines the right portions of the received packet re: application of access controls. An IPsec implementation MAY be configurable with regard to how it processes the DS field for tunnel mode for transmitted packets. For outbound traffic, one configuration setting for the DS field will operate as described in the following sections on IPv4 and IPv6 header processing for IPsec tunnels. Another will allow the DS field to be mapped to a fixed value, which MAY be configured on a per SA basis. (The value might really be fixed for all traffic outbound from a device, but per SA granularity allows that as well.) This configuration option allows a local administrator to decide whether the covert channel provided by copying these bits outweighs the benefits of copying. To: o IPsec offers certain controls to a security administrator to manage covert channels (which would not normally be a concern for tunneling) and to ensure that the receiver examines the right portions of the received packet re: application of access controls. An IPsec implementation MAY be configurable with regard to how it processes the outer DS field for tunnel mode for transmitted packets. For outbound traffic, one configuration setting for the outer DS field will operate as described in the following sections on IPv4 and IPv6 header processing for IPsec tunnels. Another will allow the outer DS field to be mapped to a fixed value, which MAY be configured on a per SA basis. (The value might really be fixed for all traffic outbound from a device, but per SA granularity allows that as well.) This configuration option allows a local administrator to decide whether the covert channel provided by copying these bits outweighs the benefits of copying. ============================================================================== 28. Mark Duffy 7.2 Separate Tunnel Mode SAs for Non-Initial Fragments, paragraph 1, next to last sentence. Clarified the motivation: From: Also, because an SA of this sort will carry ALL non-initial fragments that match a specified Local/Remote address pair and protocol value, users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms available at both peers. To: Also, an SA of this sort will carry ALL non-initial fragments that match a specified Local/Remote address pair and protocol value, i.e., the fragments carried on this SA belong to packets that, if not fragmented, might have gone on separate SAs of differing security. Therefore users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms in use between both peers. ============================================================================== 29. Mark Duffy 2.1 Goals/Objectives/Requirements/Problem Description, first paragraph, last sentence. Changed: From: These services are provided at the IP layer, offering protection for all protocols that may be carried over IP in a standard fashion (including IP itself). To: These services are provided at the IP layer, offering protection in a standard fashion for all protocols that may be carried over IP (including IP itself). ============================================================================== 30. Mark Duffy 4.4.1.1 Selectors, section on Remote IP Address and section on Local IP Address -- Changed "each a trivial ranges" to "each a trivial range" ============================================================================== 31. Mark Duffy 4.4.1.1 Selectors, section on Remote IP address -- changed last sentence of paragraph: From: Address ranges are used to support more than one destination system sharing the same SA, e.g., behind a security gateway. To: Address ranges are used to support more than one remote system sharing the same SA, e.g., behind a security gateway. ============================================================================== 32. Mark Duffy 4.4.2.1 Data Items in the SAD From: o Sequence Number Counter: a 64-bit used to generate the Sequence Number field in AH or ESP headers. 64-bit sequence numbers are the default, but 32-bit sequence numbers are also supported if negotiated. To: o Sequence Number Counter: a 64-bit counter used to generate the Sequence Number field in AH or ESP headers. 64-bit sequence numbers are the default, but 32-bit sequence numbers are also supported if negotiated. ============================================================================ 33. Mark Duffy 5.2 Processing Inbound IP Traffic (unprotected-to-protected), step 3b -- inserted the word "cache" into last sentence below: From: 3b. If the packet is not addressed to the device or is addressed to this device and is not AH or ESP, look up the packet header in the (appropriate) SPD-I cache. If there is a match and the packet is to be discarded or bypassed, do so. If there is no cache match, look up the packet in the corresponding SPD-I and create a cache entry as appropriate. (No SAs are created in response to receipt of a packet that requires IPsec protection; only BYPASS or DISCARD entries can be created this way.)..... To: 3b. If the packet is not addressed to the device or is addressed to this device and is not AH or ESP, look up the packet header in the (appropriate) SPD-I cache. If there is a match and the packet is to be discarded or bypassed, do so. If there is no cache match, look up the packet in the corresponding SPD-I and create a cache entry as appropriate. (No SAs are created in response to receipt of a packet that requires IPsec protection; only BYPASS or DISCARD cache entries can be created this way.)..... ============================================================================ 34. Mark Duffy Clarified which header info is checked upon receipt for ICMP error messages: 6.2 Processing Protected, Transit ICMP Error Messages, paragraph 4, first sentence: From: If an SA exists that accommodates an outbound ICMP error message, then the message is mapped to the SA and only the ICMP header is checked upon receipt, just as would be the case for other traffic.... To: If an SA exists that accommodates an outbound ICMP error message, then the message is mapped to the SA and only the IP and ICMP headers are checked upon receipt, just as would be the case for other traffic.... 6.2 Processing Protected, Transit ICMP Error Messages, paragraph 6, first sentence: From: If an IPsec implementation receives an inbound ICMP error message on an SA, and the header of the message does not match the traffic selectors for the SA, the receiver MUST process the received message in a special fashion. To: If an IPsec implementation receives an inbound ICMP error message on an SA, and the IP and ICMP headers of the message do not match the traffic selectors for the SA, the receiver MUST process the received message in a special fashion. ============================================================================ 35. Mark Duffy Remove some inconsistencies re: fragmenting outbound packets 5.1 Outbound IP Traffic Processing (protected-to-unprotected) -- deleted the following NOTE after step 4 NOTE: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers (or ICMP message type and code, or Mobility Header type) will match rules only having port (or ICMP message type and code, or MH type) selectors of OPAQUE or ANY. (See section 7 for more details.) 7. Handling Fragments (on the protected side of the IPsec boundary) -- deleted first sentence From: Earlier sections of this document describe mechanisms for (a) fragmenting an outbound packet after IPsec processing has been applied and reassembling it at the receiver before IPsec processing and (b) handling inbound fragments received from the unprotected side of the IPsec boundary. This section describes how an implementation should handle the processing of outbound plaintext fragments on the protected side of the IPsec boundary. (See Appendix D for discussion of Fragment Handling Rationale.) In particular, it addresses: To: This section describes how an implementation should handle the processing of outbound plaintext fragments on the protected side of the IPsec boundary. (See Appendix D for discussion of Fragment Handling Rationale.) In particular, it addresses: ============================================================================ 36. Mark Duffy 7.2 Separate Tunnel Mode SAs for Non-Initial Fragments, paragraph 3 -- corrected first sentence: From: Note: In general, for approach 2, one needs only a single SA between two implementations to carry all non-initial fragments.... To: Note: In general, for the approach described in this section, one needs only a single SA between two implementations to carry all non-initial fragments.... ============================================================================ 37. Mark Duffy 7. Handling Fragments (on the protected side of the IPsec boundary), paragraph 2 -- added sentence clarifying the meaning of a"non-trivial" selector value. From: Note: In Section 4.1, transport mode SAs have been defined to not carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two special values, ANY and OPAQUE, were defined for selectors and that ANY includes OPAQUE. To: Note: In Section 4.1, transport mode SAs have been defined to not carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two special values, ANY and OPAQUE, were defined for selectors and that ANY includes OPAQUE. The term "non-trivial" is used to mean that the selector has a value other than OPAQUE or ANY. ============================================================================ 38. Mark Duffy 13. Differences from RFC 2401 -- Deleted the following claim. It's in AH and ESP. o A definition of reserved SPIs has been added. ============================================================================ 39. Mark Duffy 5.2 Processing Inbound IP Traffic (unprotected-to-protected), step 3a -- clarified when to discard the packet. From: 3a. If the packet is addressed to the IPsec device and AH or ESP is specified as the protocol, the packet is looked up in the SAD. For unicast traffic, use only the SPI (or SPI plus protocol). For multicast traffic, use the SPI plus the destination or SPI plus destination and source addresses, as specified in section 4.1. If there is no match, discard the traffic.... To: 3a. If the packet is addressed to the IPsec device and AH or ESP is specified as the protocol, the packet is looked up in the SAD. For unicast traffic, use only the SPI (or SPI plus protocol). For multicast traffic, use the SPI plus the destination or SPI plus destination and source addresses, as specified in section 4.1. In either case (unicast or multicast), if there is no match, discard the traffic.... ============================================================================ 40 BBN 6.1.1 ICMP Error Messages Received on the Unprotected Side of the Boundary From: If an ICMP PMTU message passes the checks above and the system is configured to accept it, then it should be processed as described in Section 8.2. To: If an ICMP PMTU message passes the checks above and the system is configured to accept it, then there are two possibilities. If the implementation applies fragmentation on the ciphertext side of the boundary, then the accepted PMTU information is passed to the forwarding module (outside of the IPsec implementation) which uses it to manage outbound packet fragmentation. If the implementation is configured to effect plaintext side fragmentation, then the PMTU information is passed to the plaintext side and processed as described in Section 8.2. ============================================================================ 41 BBN 5.1 Outbound IP Traffic Processing (protected-to-unprotected), Figure 2 5.2 Processing Inbound IP Traffic (unprotected-to-protected), Figure 3 -- added note to the SPD caches in both diagrams indicating: (*) = The SPD caches are shown here. If there is a cache miss, then the SPD is checked. There is no requirement that an implementation buffer the packet if there is a cache miss. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 25 10:15:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28186 for ; Mon, 25 Oct 2004 10:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM5aS-0005Pm-98; Mon, 25 Oct 2004 10:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM5Zk-0005Hn-BX for ipsec@megatron.ietf.org; Mon, 25 Oct 2004 10:11:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27889 for ; Mon, 25 Oct 2004 10:11:54 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM5nC-0007S1-RD for ipsec@ietf.org; Mon, 25 Oct 2004 10:25:51 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PEBo5n041880 for ; Mon, 25 Oct 2004 07:11:51 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Mon, 25 Oct 2004 07:11:51 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] IPsec 2401bis -- new draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Because the Internet Drafts queue is probably jammed right now, this draft is available as . That link will go away when the draft is officially published. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 25 13:00:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13900 for ; Mon, 25 Oct 2004 13:00:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM87Y-0003ZO-1R; Mon, 25 Oct 2004 12:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7xc-0007R9-Eo for ipsec@megatron.ietf.org; Mon, 25 Oct 2004 12:44: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 MAA12791 for ; Mon, 25 Oct 2004 12:44:40 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8Av-0002YE-VU for ipsec@ietf.org; Mon, 25 Oct 2004 12:58:40 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGiS9i068932 for ; Mon, 25 Oct 2004 09:44:28 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 25 Oct 2004 09:44:26 -0700 To: IPsec WG From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ipsec] Fwd: Last Call: 'Algorithms for Internet Key Exchange version 1 (IKEv1)' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. My (non-WG) IKEv1 algorithms document is now in 4-week IETF-wide last call. Comments are obviously welcome to either of the two addresses below, and probably this list as well. --Paul Hoffman >X-test-idtracker: no >To: IETF-Announce >From: The IESG >Date: Mon, 25 Oct 2004 11:36:26 -0400 >X-Spam-Score: 0.0 (/) >X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad >Subject: Last Call: 'Algorithms for Internet Key Exchange version 1 (IKEv1)' > to Proposed Standard >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: iesg@ietf.org >List-Id: ietf-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org > >The IESG has received a request from an individual submitter to consider >the following document: > >- 'Algorithms for Internet Key Exchange version 1 (IKEv1) ' > 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-11-22. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-hoffman-ikev1-algorithms-01.txt > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 25 15:35:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26913 for ; Mon, 25 Oct 2004 15:35:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAaF-00024I-7p; Mon, 25 Oct 2004 15:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMATm-0007mK-Na for ipsec@megatron.ietf.org; Mon, 25 Oct 2004 15:26: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 PAA26395 for ; Mon, 25 Oct 2004 15:26:04 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMAhI-0005cR-4q for ipsec@ietf.org; Mon, 25 Oct 2004 15:40:04 -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 i9PJPWjf016468; Mon, 25 Oct 2004 15:25:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 25 Oct 2004 15:27:52 -0400 To: ipsec@ietf.org, Mark Duffy From: Karen Seo Subject: Fwd: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt 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: 29dc808194f5fb921c09d0040806d6eb Cc: kseo@bbn.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Mark, Folks, Sorry, this was sent to the old mailing list by mistake. Karen >X-Sender: kent@po2.bbn.com >Date: Fri, 22 Oct 2004 15:31:55 -0400 >To: Mark Duffy >From: Stephen Kent >Subject: Re: [Ipsec] WORKING GROUP LAST CALL: > draft-ietf-ipsec-rfc2401bis-03.txt >X-Scanned-By: MIMEDefang 2.35 >X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >X-Spam-Score: 0.0 (/) >X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 >Cc: ipsec@lists.tislabs.com >X-BeenThere: ipsec@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: IP Security >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: ipsec-bounces@ietf.org >X-Spam-Status: NO >Status: >Mark, > >Karen and I were reviewing all the comments we received during the >WG last call, making final change to 2401bis. Most of your comments >were easy to address, but there were some that require further >discussion, or which we feel do not merit the changes you suggest: > >>Sect 5 first paragraph: >> >>"But, if the SPD entries are first decorrelated, then the resulting >>entries can safely be cached, and each cached entry will map to >>exactly one SA, or indicate that matching traffic should be >>bypassed or discarded, appropriately. (Note: The original SPD entry >>might result in multiple SAs, e.g., because of PFP.)" >> >>As the text here points out, multiple SAs might be created pursuant >>to one SPD entry. But it seems like a bit of a leap from that to >>saying that each cached SPD entry maps to one SA. It doesn't even >>seem correct, unless the "SPD cache" *by definition of the model* >>contains entries that map to one SA each. If that is the case it >>should be so stated; otherwise the statement about each cached SPD >>entry mapping to one SA should be removed. As far as I can see, >>nothing is gained by requiring the SPD cache to be so fine-grained. > >in general, an entry in the SPD cache points to exactly one SA. this >is what one would expect because the purpose of the cache is to >speed up the mapping of outbound packets to SAs. there are >exceptions, however, and so we will revise the text. exceptions >arise when one uses multiple SAs to carry traffic of different >priorities (e.g., as indicated by distinct DSCP values) but with the >same selectors, on different SAs. > >>In sect. 5.1 item 4: >> >>" 4. The packet is passed to the outbound forwarding function >>(operating outside of the IPsec implementation), to select the >>interface to which the packet will be directed. This function may >>cause the packet to be passed back across the IPsec boundary, for >>additional IPsec processing, e.g., in support of nested SAs. If so, >>there MUST be an entry in SPD-I database that permits inbound >>bypassing of the packet, otherwise the packet will be discarded." >> >>I don't understand why the last 2 sentences are there. Let's look >>at the case of an overlay network, which I presume is one of the >>applications that might cause iterated application of IPsec. After >>once applying IPsec we have, say, an ESP packet. We do a >>forwarding lookup on the dest address of the ESP packet and that >>forwarding lookup selects another (or the same) SPD-O/SPD-S, which >>the packet is then evaluated against. Where and why does the SPD-I >>bypass rule come into play in such a scenario? Where is the packet >>"passed back across the IPsec boundary"? I think perhaps there is >>more to the model you have in mind here then I am picking up from >>the text. > >Once a packet has crossed the IPsec boundary, it cannot be processed >via IPsec again, unless it is bypassed, i.e., lopped. this is true >in both directions, inbound or outbound. If one requires multiple >passes through IPsec to protect a packet, then one must have entries >in the SPD-O/I caches to allow such bypassing, as illustrated in >Appendix E. > >>In sect. 7.4 (BYPASS/DISCARD traffic) it says "An implementation >>MUST support stateful fragment checking to accommodate BYPASS >>traffic for which a non-trivial port range is specified." This >>seems to mandate that an implementation support the type of >>stateful fragment checking that is made a MAY in 7.3. >> >>I propose that this statement be changed to include the alternative >>of dropping the non-initial fragments (which should be the normal >>behavior *anyway* if there is no applicable SPD policy with port >>selectors of ANY or OPAQUE). So I would change the above-quoted >>sentence to: >> >> "An implementation MAY BYPASS non-initial fragments pursuant to >>an SPD policy entry with a non-trivial port range if stateful >>fragment checking is performed to verify the applicable ports for >>those fragments." > >Yes, 7.3 is a MAY, but that's for protected traffic, not for BYPASS >traffic. The debate over fragment handling for IPsec-protected >traffic spilled over into BYPASS traffic as well, as documented in >Appendix D. I don't recall messages that suggest the WG decided to >drop the requirement to support fragment reassembly for BYPASS >fragments. If you can point me to the relevant messages, then we >will change the text as you suggest. > >>In sect 8.2.1 (propagation of PMTU), it says that once it has >>"learned" a new PMTU, the IPsec implementation should wait for >>outbound traffic for the SA and "When such traffic arrives, if the >>traffic would exceed the updated PMTU value the traffic MUST be >>discarded and an appropriate ICMP PMTU message sent." >> >>I think that is the correct behavior *if* the packet had DF set, >>but if it does not then the IPsec implementation should either >>fragment then encrypt or encrypt then fragment, per its >>configuration. > >Tbe processing described above is correct for IPv4 when the DF bit >is set, as you noted. It also is appropriate for IPv6, because we >can't fragment on the plaintext side for v6. maybe we could fragment >on the ciphertext side, but that is still not in the spirit of v6, >since we are an intermediate system performing fragmentation. The >question is very poor performance that results for v4 or v6 if we >fragment. How about compromise: for v6 we send the PMTU and drop >the packet, as now described; for v4 we send the PMTU message, but >still pass the packet, fragmenting on either side as configured. > >>Appendix D has not been updated to align with what was eventually >>decided, and so may lead to confusion. Perhaps it should just be >>dropped? > > >We were explicitly asked to preserve the analysis that motivated the >final text in 2401bis, hence the appendix in question. The Appendix >presents arguments for different approaches, and ends with the >observation that we settled for one MUST and two MAYs. other than >the question about fragment reassembly for BYPASS traffic, what >parts of it do you feel are no longer consistent with the final text? > >Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 26 18:57:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20128 for ; Tue, 26 Oct 2004 18:57:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYwl-0003PZ-Jj; Tue, 26 Oct 2004 17:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMY9c-0001pW-GH; Tue, 26 Oct 2004 16:42:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16465; Tue, 26 Oct 2004 16:42:50 -0400 (EDT) Message-Id: <200410262042.QAA16465@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 16:42:50 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-rfc2401bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : S. Kent, K. Seo Filename : draft-ietf-ipsec-rfc2401bis-04.txt Pages : 92 Date : 2004-10-26 This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document is based upon RFC 2401 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-rfc2401bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-26160958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2401bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160958.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Tue Oct 26 23:29:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27290 for ; Tue, 26 Oct 2004 23:29:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMeRo-0003jO-Kl; Tue, 26 Oct 2004 23:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMeQU-0003O0-PG for ipsec@megatron.ietf.org; Tue, 26 Oct 2004 23:24: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 XAA26920 for ; Tue, 26 Oct 2004 23:24:40 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMeeH-0002qf-GN for ipsec@ietf.org; Tue, 26 Oct 2004 23:38:57 -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 i9R3O5jf029787; Tue, 26 Oct 2004 23:24:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20041004135422.02dcf6b0@email> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> Date: Tue, 26 Oct 2004 23:25:54 -0400 To: Mark Duffy From: Karen Seo Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipsec@ietf.org, kseo@bbn.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Mark, I believe we've made edits per your suggestions or replied with comments/proposed approaches for all the items you listed except for the following one... >In sect 5.2 p. 51 step 3a it discussed creating an audit log entry. >It's not clear whether the auditable event would be any processing >done under step 3a, or just the multicast case discussed just before >the auditing. But, it doesn't seem in either case that it should be >an auditable event -- there is no error case or unusual occurrence >here, just normal, vanilla processing. Given that the packet specifies AH or ESP as the protocol and is addressed to this device, there should be an entry in the SAD for it. The auditable event is the failure to find a match in the SAD. This is an error and applies to both unicast or multicast packets. So the current wording seems reasonable. Do you agree? "3a. If the packet is addressed to the IPsec device and AH or ESP is specified as the protocol, the packet is looked up in the SAD. For unicast traffic, use only the SPI (or SPI plus protocol). For multicast traffic, use the SPI plus the destination or SPI plus destination and source addresses, as specified in section 4.1. In either case (unicast or multicast), if there is no match, discard the traffic. This is an auditable event...." Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 27 10:41:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09916 for ; Wed, 27 Oct 2004 10:41:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMou4-0006i5-UD; Wed, 27 Oct 2004 10:35:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMog7-00028P-FE for ipsec@megatron.ietf.org; Wed, 27 Oct 2004 10:21:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07122 for ; Wed, 27 Oct 2004 10:21:28 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMotx-00065r-MS for Ipsec@ietf.org; Wed, 27 Oct 2004 10:35:52 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9REKtCE747330 for ; Wed, 27 Oct 2004 10:20:55 -0400 Received: from d01mll83.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9REKpPe288482 for ; Wed, 27 Oct 2004 10:20:55 -0400 To: Ipsec@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Wierbowski Date: Wed, 27 Oct 2004 10:20:49 -0400 X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Build V70_M2_07222004_HF6 Beta 2NP|July 22, 2004) at 10/27/2004 10:20:54 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ipsec] What happened to Negotiation of NAT-Traversal in the IKE RFC? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 saw a posting from Tero on 9/30/2004 that contained a small list of changes to be done during the author 48 hours state. I know it is in the hands of the editor right now, but does anybody have an idea of when the 'Negotiation of NAT-Traversal in the IKE ' is going to get to the author 48 hour state? It seems we've been in the current state now for nearly 6 months. The IESG approved the 'Negotiation of NAT-Traversal in the IKE ' as a Proposed Standard back in April. Is there a place one could go to check the status to see what the delay is? I know we were waiting for IESG to approve 'UDP Encapsulation of IPsec Packets' as a proposed standard but that happened in early August. Dave Wierbowski _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 27 12:10:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19024 for ; Wed, 27 Oct 2004 12:10:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqJ2-0005U3-5e; Wed, 27 Oct 2004 12:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqBs-0003nf-HZ for ipsec@megatron.ietf.org; Wed, 27 Oct 2004 11:58:24 -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 LAA18028 for ; Wed, 27 Oct 2004 11:58:21 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMqPl-0000Ud-MJ for Ipsec@ietf.org; Wed, 27 Oct 2004 12:12:46 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RFwIF3094792; Wed, 27 Oct 2004 08:58:19 -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, 27 Oct 2004 08:58:19 -0700 To: David Wierbowski , Ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] What happened to Negotiation of NAT-Traversal in the IKE RFC? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 1.0 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:20 AM -0400 10/27/04, David Wierbowski wrote: >I saw a posting from Tero on 9/30/2004 that contained a small list of >changes to be done during the author 48 hours state. I know it is in the >hands of the editor right now, but does anybody have an idea of when the >'Negotiation of NAT-Traversal in the IKE ' is going to get to the author 48 >hour state? It seems we've been in the current state now for nearly 6 >months. The IESG approved the 'Negotiation of NAT-Traversal in the IKE ' > as a Proposed Standard back in April. >Is there a place one could go to check the status to see what the delay is? >I know we were waiting for IESG to approve 'UDP Encapsulation of IPsec >Packets' as a proposed standard but that happened in early August. It is stuck in the RFC Editor's queue. See . --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 27 16:20:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09841 for ; Wed, 27 Oct 2004 16:20:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMu79-0004qC-QF; Wed, 27 Oct 2004 16:09:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMu3w-0003SM-3m for ipsec@megatron.ietf.org; Wed, 27 Oct 2004 16:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08641 for ; Wed, 27 Oct 2004 16:06:24 -0400 (EDT) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMuHo-0005yi-3w for ipsec@ietf.org; Wed, 27 Oct 2004 16:20:51 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.230]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87X7RB1; Wed, 27 Oct 2004 16:05:49 -0400 Message-Id: <6.1.2.0.2.20041025184443.030a6b80@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 16:03:58 -0400 To: Stephen Kent , Karen Seo From: Mark Duffy Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt In-Reply-To: References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Steve and Karen, and thanks again for your efforts. I've responded below for each item. --Mark At 03:31 PM 10/22/2004, Stephen Kent wrote: >Mark, > >Karen and I were reviewing all the comments we received during the WG last >call, making final change to 2401bis. Most of your comments were easy to >address, but there were some that require further discussion, or which we >feel do not merit the changes you suggest: > >>Sect 5 first paragraph: >> >>"But, if the SPD entries are first decorrelated, then the resulting >>entries can safely be cached, and each cached entry will map to exactly >>one SA, or indicate that matching traffic should be bypassed or >>discarded, appropriately. (Note: The original SPD entry might result in >>multiple SAs, e.g., because of PFP.)" >> >>As the text here points out, multiple SAs might be created pursuant to >>one SPD entry. But it seems like a bit of a leap from that to saying >>that each cached SPD entry maps to one SA. It doesn't even seem correct, >>unless the "SPD cache" *by definition of the model* contains entries that >>map to one SA each. If that is the case it should be so stated; >>otherwise the statement about each cached SPD entry mapping to one SA >>should be removed. As far as I can see, nothing is gained by requiring >>the SPD cache to be so fine-grained. > >in general, an entry in the SPD cache points to exactly one SA. this is >what one would expect because the purpose of the cache is to speed up the >mapping of outbound packets to SAs. there are exceptions, however, and so >we will revise the text. exceptions arise when one uses multiple SAs to >carry traffic of different priorities (e.g., as indicated by distinct DSCP >values) but with the same selectors, on different SAs. I agree that if one is using the SPD cache to speed up the mapping of outbound packets one would like to have one cache entry per SA (**). However, it is my understanding that the purpose of the SPD cache *in the context of the 2401bis document* is not to speed up execution but to model the desired behavior under the standard. Therefore I suggest two changes to the wording: . State somewhere that for the purposes of this specification, it is assumed that there is one SPD cache entry for every SA (**). . The wording from rfc2401bis-03 that is quoted above implies that the cache-entry-per-SA is a *consequence* of the decorrelation, i.e. it says "... if the SPD entries are first decorrelated, then ... and each cached entry will map to exactly one SA ...". This was the cause of my original comment. I suggest changing this text to e.g. "But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached. Each cached entry will indicate that matching traffic should be bypassed or discarded, appropriately." (**) I agree that multiple SAs for the same selector set but for different DSCPs would share an SPD cache entry. One way to capture this would be to replace statements like: "each cached entry will map to exactly one SA, or ... bypassed or discarded" with: "each cached entry will map to one or more SAs with the same selector set, or ... bypassed or discarded" >>In sect. 5.1 item 4: >> >>" 4. The packet is passed to the outbound forwarding function (operating >>outside of the IPsec implementation), to select the interface to which >>the packet will be directed. This function may cause the packet to be >>passed back across the IPsec boundary, for additional IPsec processing, >>e.g., in support of nested SAs. If so, there MUST be an entry in SPD-I >>database that permits inbound bypassing of the packet, otherwise the >>packet will be discarded." >> >>I don't understand why the last 2 sentences are there. Let's look at the >>case of an overlay network, which I presume is one of the applications >>that might cause iterated application of IPsec. After once applying >>IPsec we have, say, an ESP packet. We do a forwarding lookup on the dest >>address of the ESP packet and that forwarding lookup selects another (or >>the same) SPD-O/SPD-S, which the packet is then evaluated against. Where >>and why does the SPD-I bypass rule come into play in such a >>scenario? Where is the packet "passed back across the IPsec >>boundary"? I think perhaps there is more to the model you have in mind >>here then I am picking up from the text. > >Once a packet has crossed the IPsec boundary, it cannot be processed via >IPsec again, unless it is bypassed, i.e., lopped. this is true in both >directions, inbound or outbound. If one requires multiple passes through >IPsec to protect a packet, then one must have entries in the SPD-O/I >caches to allow such bypassing, as illustrated in Appendix E. The way I am looking at it, once a SG has applied tunnel mode IPsec to a packet, it has created a *new* IP packet that is from the SG itself. I view this new packet as originating *inside* the IPsec boundary (comparable to the way that, say, IKE packets from the SG originate from inside the IPsec boundary). If on the other hand an SG is to view the tunnel mode packet that it just created as having arrived from outside the IPsec boundary, that seems to me to be quite confusing. What interface would it be considered to have arrived from? Which (of potentially multiple) SPDs should be used for the pseudo-inbound processing? How do I (configuring the policy) distinguish these packets from ones that really came in off the network? At the bottom line, why should an SG treat an IPsec packet that it just created as though it just arrived on an unprotected interface? >>In sect. 7.4 (BYPASS/DISCARD traffic) it says "An implementation MUST >>support stateful fragment checking to accommodate BYPASS traffic for >>which a non-trivial port range is specified." This seems to mandate that >>an implementation support the type of stateful fragment checking that is >>made a MAY in 7.3. >> >>I propose that this statement be changed to include the alternative of >>dropping the non-initial fragments (which should be the normal behavior >>*anyway* if there is no applicable SPD policy with port selectors of ANY >>or OPAQUE). So I would change the above-quoted sentence to: >> >> "An implementation MAY BYPASS non-initial fragments pursuant to an >> SPD policy entry with a non-trivial port range if stateful fragment >> checking is performed to verify the applicable ports for those fragments." > >Yes, 7.3 is a MAY, but that's for protected traffic, not for BYPASS >traffic. The debate over fragment handling for IPsec-protected traffic >spilled over into BYPASS traffic as well, as documented in Appendix D. I >don't recall messages that suggest the WG decided to drop the requirement >to support fragment reassembly for BYPASS fragments. If you can point me >to the relevant messages, then we will change the text as you suggest. I don't know of any relevant messages, either for or against this, for bypass traffic. However, it seems to me that the whole stateful fragment checking question is about the same for PROTECT and for BYPASS. I think all the same arguments could be made on all sides. Therefore I would assume that the decision reached should be the same for PROTECT and for BYPASS. Since we had the big discussion for PROTECT and decided that stateful fragment checking is a MAY, I would expect the same conclusion to apply for BYPASS. However, you seem to be taking the position that unless this was specifically discussed for BYPASS, that the standard in this area is defaulting to MUST. I don't see why that should be the case. >>In sect 8.2.1 (propagation of PMTU), it says that once it has "learned" a >>new PMTU, the IPsec implementation should wait for outbound traffic for >>the SA and "When such traffic arrives, if the traffic would exceed the >>updated PMTU value the traffic MUST be discarded and an appropriate ICMP >>PMTU message sent." >> >>I think that is the correct behavior *if* the packet had DF set, but if >>it does not then the IPsec implementation should either fragment then >>encrypt or encrypt then fragment, per its configuration. > >Tbe processing described above is correct for IPv4 when the DF bit is set, >as you noted. It also is appropriate for IPv6, because we can't fragment >on the plaintext side for v6. maybe we could fragment on the ciphertext >side, but that is still not in the spirit of v6, since we are an >intermediate system performing fragmentation. The question is very poor >performance that results for v4 or v6 if we fragment. How >about compromise: for v6 we send the PMTU and drop the packet, as now >described; for v4 we send the PMTU message, but still pass the packet, >fragmenting on either side as configured. Let me break it into 3 cases: 1. Original (cleartext) packet is IPv4 and has DF set: I think you and I are agreed that it should discard the packet, and send a PMTU ICMP message. 2. Original (cleartext) packet is IPv4 and has DF clear: I think you are suggesting that the IPsec implementation send a PMTU ICMP message but also fragment (before or after IPsec) and forward the packet. I disagree with that. I agree it should fragment and forward the packet, but I DO NOT agree that it should send the PMTU ICMP. The reason is that the ICMP message that would be sent is type 3 (Destination Unreachable) code 4 ("fragmentation needed and DF set"). I do not think it is good practice to send "fragmentation needed and DF set" in cases where DF was not set. 3. Original (cleartext) packet is IPv6: I think you and I are agreed that this should be treated just like case 1. BTW I think the above cases cover all cases, regardless of whether a tunnel mode IPsec encapsulation would be IPv4 or v6. >>Appendix D has not been updated to align with what was eventually >>decided, and so may lead to confusion. Perhaps it should just be dropped? > > >We were explicitly asked to preserve the analysis that motivated the final >text in 2401bis, hence the appendix in question. The Appendix presents >arguments for different approaches, and ends with the observation that we >settled for one MUST and two MAYs. other than the question about fragment >reassembly for BYPASS traffic, what parts of it do you feel are no longer >consistent with the final text? Re-reading the appendix now, it doesn't strike me as badly as last time :-) so I will largely withdraw this complaint. The only thing I see from a quick look (maybe only a nit, I'll concede): "...essentially create a "non-initial fragment only" SA, precisely the solution that the WG rejected." and "The Working Group rejected the convention of creating an SA to carry only non-initial fragments" As reflected in sect 7.2, separate SAs may be used for non-initial fragments. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 27 23:36:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12937 for ; Wed, 27 Oct 2004 23:36:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN12P-0007KJ-2C; Wed, 27 Oct 2004 23:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN11R-0007E0-LF for ipsec@megatron.ietf.org; Wed, 27 Oct 2004 23:32: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 XAA12611 for ; Wed, 27 Oct 2004 23:32:18 -0400 (EDT) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN1FQ-0006Kp-9n for ipsec@ietf.org; Wed, 27 Oct 2004 23:46:49 -0400 Received: from MDUFFY1.quarrytech.com (rocket.quarrytech.com [10.1.1.127]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87X7SJ4; Wed, 27 Oct 2004 23:31:49 -0400 Message-Id: <6.1.2.0.2.20041027232644.02e5bd18@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 27 Oct 2004 23:29:45 -0400 To: Karen Seo From: Mark Duffy Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt In-Reply-To: References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> Mime-Version: 1.0 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 >>In sect 5.2 p. 51 step 3a it discussed creating an audit log entry. It's >>not clear whether the auditable event would be any processing done under >>step 3a, or just the multicast case discussed just before the >>auditing. But, it doesn't seem in either case that it should be an >>auditable event -- there is no error case or unusual occurrence here, >>just normal, vanilla processing. > > Given that the packet specifies AH or ESP as the protocol > and is addressed to this device, there should be an entry > in the SAD for it. The auditable event is the failure to > find a match in the SAD. This is an error and applies > to both unicast or multicast packets. So the current > wording seems reasonable. Do you agree? > > "3a. If the packet is addressed to the IPsec device and > AH or ESP is specified as the protocol, the packet is > looked up in the SAD. For unicast traffic, use only the > SPI (or SPI plus protocol). For multicast traffic, use > the SPI plus the destination or SPI plus destination and > source addresses, as specified in section 4.1. In either > case (unicast or multicast), if there is no match, discard > the traffic. This is an auditable event...." Thanks Karen, that looks great. (I think the -03 draft was actually missing a whole line of text here, which was the main problem.) --Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 00:05:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16153 for ; Thu, 28 Oct 2004 00:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN1V7-00027d-9q; Thu, 28 Oct 2004 00:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN1Uj-00022H-Ua for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 00:02: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 AAA15855 for ; Thu, 28 Oct 2004 00:02:34 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN1iZ-00075h-9X for ipsec@ietf.org; Thu, 28 Oct 2004 00:17:06 -0400 Received: from jyothi.intotoinc.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i9S42H0Q009296 for ; Thu, 28 Oct 2004 09:32:18 +0530 Message-Id: <5.1.0.14.0.20041028090205.0304d710@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Oct 2004 09:35:47 +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-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ipsec] Reauthentication 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 Hi all, I have some questions regarding the Reauthentication in IKEv2. 1. CREATE_CHILD_SA exchange is supported. In this when the IKE SA lifetime is completed, we use CREATE_CHILD_SA exchange and form new IKE SA keys. Is it required to reauthenticate the peer may be after some time??? If reauthentication is required, in case of EAP authentication, it says that CLIENT may use the EAP Fast reauthentication ID in IKE exchange. In this case IKE policy lookup may fail, if we are searching with the received identity. If reauthentication is required, what is the best way to proceed?? May be the responder has to maintain some mapping between policy identity and EAP negotiated identity. 2. CREATE_CHILD_SA exchange is not supported In this case, peer will always authenticate. If EAP authentication is used, do we have to go for EAP re-authentication??? Awaiting your responses. Thanks in advance, Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 01:17:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21109 for ; Thu, 28 Oct 2004 01:17:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN2cb-0006jF-Pj; Thu, 28 Oct 2004 01:14:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN2a8-0006Om-9e for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 01:12:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20846 for ; Thu, 28 Oct 2004 01:12:14 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN2o6-0008Fg-NI for ipsec@ietf.org; Thu, 28 Oct 2004 01:26:43 -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 i9S5Bfjf029799; Thu, 28 Oct 2004 01:11:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20041027232644.02e5bd18@localhost> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041027232644.02e5bd18@localhost> Date: Thu, 28 Oct 2004 01:13:33 -0400 To: Mark Duffy From: Karen Seo Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt 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: 52e1467c2184c31006318542db5614d5 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Mark, You're right -- the -03 draft is missing a critical sentence. Thanks for catching this. Karen >>>In sect 5.2 p. 51 step 3a it discussed creating an audit log >>>entry. It's not clear whether the auditable event would be any >>>processing done under step 3a, or just the multicast case >>>discussed just before the auditing. But, it doesn't seem in >>>either case that it should be an auditable event -- there is no >>>error case or unusual occurrence here, just normal, vanilla >>>processing. >> >> Given that the packet specifies AH or ESP as the protocol >> and is addressed to this device, there should be an entry >> in the SAD for it. The auditable event is the failure to >> find a match in the SAD. This is an error and applies >> to both unicast or multicast packets. So the current >> wording seems reasonable. Do you agree? >> >> "3a. If the packet is addressed to the IPsec device and >> AH or ESP is specified as the protocol, the packet is >> looked up in the SAD. For unicast traffic, use only the >> SPI (or SPI plus protocol). For multicast traffic, use >> the SPI plus the destination or SPI plus destination and >> source addresses, as specified in section 4.1. In either >> case (unicast or multicast), if there is no match, discard >> the traffic. This is an auditable event...." > >Thanks Karen, that looks great. >(I think the -03 draft was actually missing a whole line of text >here, which was the main problem.) >--Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 02:31:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09824 for ; Thu, 28 Oct 2004 02:31:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN3kN-0001aP-4x; Thu, 28 Oct 2004 02:26:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN3jo-0001I2-Kh for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 02:26: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 CAA09491 for ; Thu, 28 Oct 2004 02:26:20 -0400 (EDT) From: Pasi.Eronen@Nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN3xo-00010i-Mf for ipsec@ietf.org; Thu, 28 Oct 2004 02:40:50 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9S6QEl13590; Thu, 28 Oct 2004 09:26:14 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 09:25:48 +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 i9S6PmFs008234; Thu, 28 Oct 2004 09:25:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00RjxoRq; Thu, 28 Oct 2004 09:25:47 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 i9S6Pla20350; Thu, 28 Oct 2004 09:25:47 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 09:25:36 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 09:25:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 09:25:36 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178393@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] Reauthentication in IKEv2 Thread-Index: AcS8o/Rflo9fdOYPTYyd0QhdhH8AuQADnUDA To: , X-OriginalArrivalTime: 28 Oct 2004 06:25:35.0952 (UTC) FILETIME=[EF62DD00:01C4BCB6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, Do you mean reauthentication or rekeying an IKE SA? These are not the same in IKEv2: although reauthentication always does rekeying as well, the reverse is not true; and=20 there are two separate lifetimes ("key lifetime" can be=20 shorter than "authentication lifetime").=20 CREATE_CHILD_SA exchange is related to rekeying without reauthentication, so EAP is not involved. Reauthentication is done by establishing a new IKE SA from scratch, creating new child SAs (equivalent to the old ones), and finally deleting=20 the old IKE SA. For policy lookups, it's very important to use the identity (identifier) that was actually authenticated by the EAP method, and this is not necessarily the same as IDi. Many EAP methods have an internal identity exchange, and the initial identity (e.g., IDi or EAP Identity Response) is used only for AAA routing and selecting which method to use (see RFC 3748, sections 5.1 and 7.3). "Reauthentication identities" in some=20 EAP methods are an obvious example where using IDi for policy=20 lookups fails, but that's not the main reason. Best regards, Pasi > -----Original Message----- > From: Jyothi > Sent: Thursday, October 28, 2004 7:06 AM > To: ipsec@ietf.org > Subject: [Ipsec] Reauthentication in IKEv2 >=20 >=20 > Hi all, >=20 > I have some questions regarding the Reauthentication in IKEv2. >=20 > 1. CREATE_CHILD_SA exchange is supported. >=20 > In this when the IKE SA lifetime is completed, we use > CREATE_CHILD_SA exchange and form new IKE SA keys. >=20 > Is it required to reauthenticate the peer may be after some > time??? >=20 > If reauthentication is required, in case of EAP > authentication, it says that CLIENT may use the EAP Fast > reauthentication ID in IKE exchange. >=20 > In this case IKE policy lookup may fail, if we are searching > with the received identity. >=20 > If reauthentication is required, what is the best way to proceed?? >=20 > May be the responder has to maintain some mapping between > policy identity and EAP negotiated identity. >=20 > 2. CREATE_CHILD_SA exchange is not supported >=20 > In this case, peer will always authenticate. >=20 > If EAP authentication is used, do we have to go for EAP=20 > re-authentication??? >=20 > Awaiting your responses. >=20 > Thanks in advance, > Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 03:41:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15251 for ; Thu, 28 Oct 2004 03:41:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN4s0-0004Hf-GR; Thu, 28 Oct 2004 03:38:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN4rh-0004B1-Ma for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 03:38:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14969 for ; Thu, 28 Oct 2004 03:38:32 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN55h-0002HK-OV for ipsec@ietf.org; Thu, 28 Oct 2004 03:53:03 -0400 Received: from intoto8.intotoinc.com (2mc62.intotoind.com [172.16.2.62]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i9S7cHEo014602; Thu, 28 Oct 2004 13:08:18 +0530 Message-Id: <5.1.0.14.0.20041028125654.02709990@172.16.1.10> X-Sender: umas@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Oct 2004 13:12:22 +0530 To: Pasi.Eronen@Nokia.com, , From: Uma Shankar Ch Subject: RE: [Ipsec] Reauthentication in IKEv2 In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178393@esebe056.ntc.nokia. com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c X-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="===============0530640912==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0530640912== Content-Type: multipart/alternative; boundary="=====================_89103727==_.ALT" --=====================_89103727==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed For policy lookups, it's very important to use the identity (identifier) that was actually authenticated by the EAP method, and this is not necessarily the same as IDi. Many EAP methods have an internal identity exchange, and the initial identity (e.g., IDi or EAP Identity Response) is used only for AAA routing and selecting which method to use (see RFC 3748, sections 5.1 and 7.3). "Reauthentication identities" in some EAP methods are an obvious example where using IDi for policy lookups fails, but that's not the main reason. Uma: So, initiator wants to send the new authenticated identity by EAP Method (Say fast re authentication ID) what could be the options at Responder side, so that it could successfully identify policy and can relay the same to EAP Server ---which eventually could cause Successful EAP Re Authentication too. It seems with this, Is it that, in the re authentication of IKE_SA case also IDi would be the same original IDi ???? and with this Responder would relay the same and can't use the Re Authentication facility provided by EAP Method?? Or Really is there any other way, so that initiator can send two ID's one is the original IDi for policy matching and the second is the Authenticated EAP Re authentication ID to have EAP Re-authentication facility????? (It's not correct/possible) Regards, --Uma At 09:25 AM 10/28/04 +0300, Pasi.Eronen@Nokia.com wrote: >Hi, > >Do you mean reauthentication or rekeying an IKE SA? > >These are not the same in IKEv2: although reauthentication >always does rekeying as well, the reverse is not true; and >there are two separate lifetimes ("key lifetime" can be >shorter than "authentication lifetime"). > >CREATE_CHILD_SA exchange is related to rekeying without >reauthentication, so EAP is not involved. Reauthentication is >done by establishing a new IKE SA from scratch, creating new >child SAs (equivalent to the old ones), and finally deleting >the old IKE SA. > >For policy lookups, it's very important to use the identity >(identifier) that was actually authenticated by the EAP method, >and this is not necessarily the same as IDi. Many EAP methods >have an internal identity exchange, and the initial identity >(e.g., IDi or EAP Identity Response) is used only for AAA >routing and selecting which method to use (see RFC 3748, >sections 5.1 and 7.3). "Reauthentication identities" in some >EAP methods are an obvious example where using IDi for policy >lookups fails, but that's not the main reason. > >Best regards, >Pasi > > > -----Original Message----- > > From: Jyothi > > Sent: Thursday, October 28, 2004 7:06 AM > > To: ipsec@ietf.org > > Subject: [Ipsec] Reauthentication in IKEv2 > > > > > > Hi all, > > > > I have some questions regarding the Reauthentication in IKEv2. > > > > 1. CREATE_CHILD_SA exchange is supported. > > > > In this when the IKE SA lifetime is completed, we use > > CREATE_CHILD_SA exchange and form new IKE SA keys. > > > > Is it required to reauthenticate the peer may be after some > > time??? > > > > If reauthentication is required, in case of EAP > > authentication, it says that CLIENT may use the EAP Fast > > reauthentication ID in IKE exchange. > > > > In this case IKE policy lookup may fail, if we are searching > > with the received identity. > > > > If reauthentication is required, what is the best way to proceed?? > > > > May be the responder has to maintain some mapping between > > policy identity and EAP negotiated identity. > > > > 2. CREATE_CHILD_SA exchange is not supported > > > > In this case, peer will always authenticate. > > > > If EAP authentication is used, do we have to go for EAP > > re-authentication??? > > > > Awaiting your responses. > > > > Thanks in advance, > > Jyothi > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec --=====================_89103727==_.ALT Content-Type: text/html; charset="us-ascii" For policy lookups, it's very important to use the identity
(identifier) that was actually authenticated by the EAP method,
and this is not necessarily the same as IDi. Many EAP methods
have an internal identity exchange, and the initial identity
(e.g., IDi or EAP Identity Response) is used only for AAA
routing and selecting which method to use (see RFC 3748,
sections 5.1 and 7.3). "Reauthentication identities" in some
EAP methods are an obvious example where using IDi for policy
lookups fails, but that's not the main reason.

Uma: So, initiator wants to send the new authenticated identity by EAP Method (Say fast re authentication ID) what could be  the options at Responder side, so that it could successfully identify policy and can relay the same to EAP Server ---which eventually could cause Successful EAP Re Authentication too.

It seems with this,
Is it that, in the re authentication of IKE_SA case also IDi would be the same original IDi ???? and with this Responder  would relay the same and can't use the Re Authentication facility provided by EAP Method??
Or Really is there any other way, so that initiator can send two ID's one is the original IDi for policy matching and the second is the Authenticated EAP Re authentication ID to have EAP Re-authentication facility????? (It's not correct/possible)
Regards,
--Uma


At 09:25 AM 10/28/04 +0300, Pasi.Eronen@Nokia.com wrote:
Hi,

Do you mean reauthentication or rekeying an IKE SA?

These are not the same in IKEv2: although reauthentication
always does rekeying as well, the reverse is not true; and
there are two separate lifetimes ("key lifetime" can be
shorter than "authentication lifetime").

CREATE_CHILD_SA exchange is related to rekeying without
reauthentication, so EAP is not involved. Reauthentication is
done by establishing a new IKE SA from scratch, creating new
child SAs (equivalent to the old ones), and finally deleting
the old IKE SA.

For policy lookups, it's very important to use the identity
(identifier) that was actually authenticated by the EAP method,
and this is not necessarily the same as IDi. Many EAP methods
have an internal identity exchange, and the initial identity
(e.g., IDi or EAP Identity Response) is used only for AAA
routing and selecting which method to use (see RFC 3748,
sections 5.1 and 7.3). "Reauthentication identities" in some
EAP methods are an obvious example where using IDi for policy
lookups fails, but that's not the main reason.

Best regards,
Pasi

> -----Original Message-----
> From: Jyothi
> Sent: Thursday, October 28, 2004 7:06 AM
> To: ipsec@ietf.org
> Subject: [Ipsec] Reauthentication in IKEv2
>
>
> Hi all,
>
> I have some questions regarding the Reauthentication in IKEv2.
>
> 1. CREATE_CHILD_SA exchange is supported.
>
> In this when the IKE SA lifetime is completed, we use
> CREATE_CHILD_SA exchange and form new IKE SA keys.
>
> Is it required to reauthenticate the peer may be after some
> time???
>
> If reauthentication is required, in case of EAP
> authentication, it says that CLIENT may use the EAP Fast
> reauthentication ID in IKE exchange.
>
> In this case IKE policy lookup may fail, if we are searching
> with the received identity.
>
> If reauthentication is required, what is the best way to proceed??
>
> May be the responder has to maintain some mapping between
> policy identity and EAP negotiated identity.
>
> 2. CREATE_CHILD_SA exchange is not supported
>
> In this case, peer will always authenticate.
>
> If EAP authentication is used, do we have to go for EAP
> re-authentication???
>
> Awaiting your responses.
>
> Thanks in advance,
> Jyothi

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--=====================_89103727==_.ALT-- --===============0530640912== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0530640912==-- From ipsec-bounces@ietf.org Thu Oct 28 04:26:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18617 for ; Thu, 28 Oct 2004 04:26:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN5Zm-0001v1-DB; Thu, 28 Oct 2004 04:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN5YF-0001f0-3u for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 04:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18404 for ; Thu, 28 Oct 2004 04:22:29 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN5mD-0003Gt-NG for ipsec@ietf.org; Thu, 28 Oct 2004 04:37:01 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9S8MNe03710; Thu, 28 Oct 2004 11:22:23 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 11:22:16 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9S8MGSw022203; Thu, 28 Oct 2004 11:22:16 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00eOethz; Thu, 28 Oct 2004 11:22:16 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9S8MGS06746; Thu, 28 Oct 2004 11:22:16 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 11:22:13 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 11:22:14 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 11:22:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 11:22:13 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178394@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] Reauthentication in IKEv2 Thread-Index: AcS8wakDfzyDu1YhSWqbuvkg8gGxYgAAqfFg To: , , X-OriginalArrivalTime: 28 Oct 2004 08:22:13.0827 (UTC) FILETIME=[3A71D930:01C4BCC7] X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable umas@intotoinc.com writes: >> For policy lookups, it's very important to use the identity >> (identifier) that was actually authenticated by the EAP >> method, and this is not necessarily the same as IDi. Many EAP >> methods have an internal identity exchange, and the initial >> identity (e.g., IDi or EAP Identity Response) is used only >> for AAA routing and selecting which method to use (see RFC >> 3748, sections 5.1 and 7.3). "Reauthentication identities" in >> some EAP methods are an obvious example where using IDi for >> policy lookups fails, but that's not the main reason. > Uma: So, initiator wants to send the new authenticated > identity by EAP Method (Say fast re authentication ID) what > could be=A0the options at Responder side, so that it could > successfully identify policy and can relay the same to EAP > Server ---which eventually could cause Successful EAP Re > Authentication too. The responder (acting as EAP pass-through authenticator) does not, in general, know the real identity that will be authenticated=20 by the EAP method before the EAP method starts.=20 But fortunately this is not even necessary; the identity sent by=20 the client (e.g., fast reauthentication id) still contains enough=20 information to select the right AAA server and EAP method; and=20 other policy lookups can be done after EAP is finished. > It seems with this, Is it that, in the re authentication of > IKE_SA case also IDi would be the same original IDi ???? and > with this Responder=A0 would relay the same and can't use the Re > Authentication facility provided by EAP Method?? Or Really is > there any other way, so that initiator can send two ID's one > is the original IDi for policy matching and the second is the > Authenticated EAP Re authentication ID to have EAP > Re-authentication facility????? (It's not correct/possible) The real identifier that was authenticated with EAP has to come from the AAA server, not the initiator. With RADIUS, this means the server has to include something in the=20 Access-Accept message (e.g., User-Name attribute). (See, e.g., draft-ietf-aaa-eap-09 (section 2.8.1), or draft-adrangi-radius-chargeable-user-identity-02.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 04:56:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20737 for ; Thu, 28 Oct 2004 04:56:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN62k-0005AO-RX; Thu, 28 Oct 2004 04:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN5z2-0004i4-Mz for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 04:50: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 EAA20252 for ; Thu, 28 Oct 2004 04:50:11 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN6D4-0003oE-Ok for ipsec@ietf.org; Thu, 28 Oct 2004 05:04:43 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i9S8nd007795; Thu, 28 Oct 2004 10:49:39 +0200 (IST) In-Reply-To: <5.1.0.14.0.20041028090205.0304d710@172.16.1.10> References: <5.1.0.14.0.20041028090205.0304d710@172.16.1.10> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84E4353E-28BE-11D9-AE0F-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 10:51:12 +0200 To: Jyothi X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Jyothi. As others have said, in IKEv2 there is only re-keying, no re-authentication. If you want the client to re-authenticate, than the client needs to re-do the initial exchange. The gateway cannot be the initiator, especially in the case of EAP. The missing piece is a way for the gateway to inform the client that the client needs to re-authenticate. I think this draft solves this issue, but when I first published it, there was little interest in the WG. I guess not many see gateway-controlled (or periodic) re-authentication as important. If you feel differently, please let me know. http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt Yoav On Oct 28, 2004, at 6:05 AM, Jyothi wrote: > Hi all, > > I have some questions regarding the Reauthentication in IKEv2. > > 1. CREATE_CHILD_SA exchange is supported. > > In this when the IKE SA lifetime is completed, we use CREATE_CHILD_SA > exchange and form new IKE SA keys. > > Is it required to reauthenticate the peer may be after some time??? > > If reauthentication is required, in case of EAP authentication, it > says that CLIENT may use the EAP Fast reauthentication ID in IKE > exchange. > > In this case IKE policy lookup may fail, if we are searching with the > received identity. > > If reauthentication is required, what is the best way to proceed?? > > May be the responder has to maintain some mapping between policy > identity and EAP negotiated identity. > > 2. CREATE_CHILD_SA exchange is not supported > > In this case, peer will always authenticate. > > If EAP authentication is used, do we have to go for EAP > re-authentication??? > > Awaiting your responses. > > 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 Oct 28 06:02:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25704 for ; Thu, 28 Oct 2004 06:02:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN75I-0000IU-Mn; Thu, 28 Oct 2004 06:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN70Z-00083C-Kp for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 05:55:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25056 for ; Thu, 28 Oct 2004 05:55:49 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN7Ec-00058V-7f for ipsec@ietf.org; Thu, 28 Oct 2004 06:10:22 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5217589830; Thu, 28 Oct 2004 12:55:48 +0300 (EEST) Message-ID: <4180C1BE.80002@kolumbus.fi> Date: Thu, 28 Oct 2004 12:54:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@Nokia.com Subject: Policy lookups (Was: [Ipsec] Reauthentication in IKEv2) References: <125EA890549C8641A72F3809CB80DCCD178393@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178393@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Pasi, > For policy lookups, it's very important to use the identity > (identifier) that was actually authenticated by the EAP method, > and this is not necessarily the same as IDi. Many EAP methods > have an internal identity exchange, and the initial identity > (e.g., IDi or EAP Identity Response) is used only for AAA > routing and selecting which method to use (see RFC 3748, > sections 5.1 and 7.3). "Reauthentication identities" in some > EAP methods are an obvious example where using IDi for policy > lookups fails, but that's not the main reason. I agree, but is this specified somewhere? RFC2401bis-04 has this text: 1. A named SPD entry is used by a responder (not an initiator) in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for "road warriors." The name used to match this field is communicated during the IKE negotiation in the ID payload. In this context, the initiator's Source IP address (inner IP header in tunnel mode) is bound to the Remote IP address in the SAD entry created by the IKE negotiation. This address overrides the Remote IP address value in the SPD, when the SPD entry is selected in this fashion. All IPsec implementations MUST support this use of names. This seems to talk about the ID payload, not the value communicated from the AAA server. Does the text need to be updated, or am I missing something? Secondly, the remote (inner) IP address presumably may come from RADIUS too? Finally, I wonder how the named SPD entry setup should be administered. Lets assume there are a million potential users in the service provider's RADIUS (or Diameter) database. Is there going to have to be a million SPD entries too in the gateway, or an the RADIUS responses point to a "class" entry for a particular type of a user (e.g., "subscriber" and "administrator")? --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 06:22:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27603 for ; Thu, 28 Oct 2004 06:22:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN7OS-0004ne-VF; Thu, 28 Oct 2004 06:20:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN7Lt-0004Hv-86 for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 06:17:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27324 for ; Thu, 28 Oct 2004 06:17:51 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN7Zw-0005e3-5v for ipsec@ietf.org; Thu, 28 Oct 2004 06:32:24 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SAHa325018; Thu, 28 Oct 2004 13:17:36 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 13:17:32 +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 i9SAHWe9015879; Thu, 28 Oct 2004 13:17:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 0017fRKN; Thu, 28 Oct 2004 13:17:30 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SAHKS01563; Thu, 28 Oct 2004 13:17:20 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 13:15:32 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 13:15:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 13:15:32 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] Reauthentication in IKEv2 Thread-Index: AcS8zMi8XBuRK3BkSseAD85Ov3hBvwAB8WrA To: X-OriginalArrivalTime: 28 Oct 2004 10:15:32.0544 (UTC) FILETIME=[0ECBBC00:01C4BCD7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Yoav Nir writes: >=20 > Hi Jyothi. >=20 > As others have said, in IKEv2 there is only re-keying, no=20 > re-authentication. If you want the client to re-authenticate,=20 > than the client needs to re-do the initial exchange. The=20 > gateway cannot be the initiator, especially in the case of EAP. >=20 > The missing piece is a way for the gateway to inform the client=20 > that the client needs to re-authenticate. I think this draft=20 > solves this issue, but when I first published it, there was=20 > little interest in the WG. I guess not many see gateway- > controlled (or periodic) re-authentication as important. If=20 > you feel differently, please let me know. >=20 > http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt Yoav, I think this is an important issue, and the approach presented in your draft is a good and simple way to solve it.=20 Please continue work towards publishing this as an RFC! WG chairs (& others), do you think that going for individual submission for standards track would be the appropriate way to proceed? Or would an informational document and/or making=20 this a WG item be better? Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 07:44:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03633 for ; Thu, 28 Oct 2004 07:44:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8g1-0001Pi-WC; Thu, 28 Oct 2004 07:42:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8dM-0000yU-OX for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 07:40:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03169 for ; Thu, 28 Oct 2004 07:40:00 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN8rQ-00074d-CQ for ipsec@ietf.org; Thu, 28 Oct 2004 07:54:33 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SBdal19968; Thu, 28 Oct 2004 14:39:51 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 14:38:56 +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 i9SBcucG024823; Thu, 28 Oct 2004 14:38:56 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00U4TAzY; Thu, 28 Oct 2004 14:38:54 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SBcsS00903; Thu, 28 Oct 2004 14:38:54 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 14:38:54 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 14:38:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Policy lookups (Was: [Ipsec] Reauthentication in IKEv2) Date: Thu, 28 Oct 2004 14:38:33 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD7B@esebe056.ntc.nokia.com> Thread-Topic: Policy lookups (Was: [Ipsec] Reauthentication in IKEv2) Thread-Index: AcS81H6yqAP7J/XZRPinLPrehRzPUQACC46A To: X-OriginalArrivalTime: 28 Oct 2004 11:38:33.0980 (UTC) FILETIME=[A7F68BC0:01C4BCE2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Jari Arkko writes: >=20 > Hi Pasi, >=20 > > For policy lookups, it's very important to use the identity > > (identifier) that was actually authenticated by the EAP method, > > and this is not necessarily the same as IDi. Many EAP methods > > have an internal identity exchange, and the initial identity > > (e.g., IDi or EAP Identity Response) is used only for AAA > > routing and selecting which method to use (see RFC 3748, > > sections 5.1 and 7.3). "Reauthentication identities" in some=20 > > EAP methods are an obvious example where using IDi for policy=20 > > lookups fails, but that's not the main reason. >=20 > I agree, but is this specified somewhere? RFC2401bis-04 has > this text: >=20 > 1. A named SPD entry is used by a responder (not an > initiator) in support of access control when an IP > address would not be appropriate for the Remote IP > address selector, e.g., for "road warriors." The name > used to match this field is communicated during the IKE > negotiation in the ID payload. In this context, the > initiator's Source IP address (inner IP header in tunnel > mode) is bound to the Remote IP address in the SAD entry > created by the IKE negotiation. This address overrides > the Remote IP address value in the SPD, when the SPD > entry is selected in this fashion. All IPsec > implementations MUST support this use of names. >=20 > This seems to talk about the ID payload, not the value > communicated from the AAA server. Does the text need to be > updated, or am I missing something? > > Secondly, the remote (inner) IP address presumably may=20 > come from RADIUS too? Clearly it's already possible to e.g. use some value from the certificate for policy lookup (instead of the IDi payload),=20 so in that sense, EAP doesn't change anything.=20 And I don't think it matters whether the IP address comes from RADIUS server or an internal pool maintained by the gateway: in either case, it comes from somewhere "outside" the functionality described in 2401bis. I guess the confusion is mostly because even with the addition of PAD, 2401bis does not very clearly separate which parts of SPD are used during per-packet processing in the kernel, and which are only used during IKE negotiation. And the parts used only by IKE are not that close to what actual implementations do... (Of course, it's not even the intention of 2401bis to document actual implementations, and it is explained that e.g. the databases are only nominal, and not the way the information=20 has to be stored.) > Finally, I wonder how the named SPD entry setup should be > administered. Lets assume there are a million potential users > in the service provider's RADIUS (or Diameter) database. Is > there going to have to be a million SPD entries too in the > gateway, or an the RADIUS responses point to a "class" entry > for a particular type of a user (e.g., "subscriber" and > "administrator")? Fortunately, no; this is one part where the real implementations don't match the "nominal SPD" that closely.. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 09:14:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10462 for ; Thu, 28 Oct 2004 09:14:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNA36-0000fY-Dy; Thu, 28 Oct 2004 09:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNA15-0008U9-7e for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 09:08:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09921 for ; Thu, 28 Oct 2004 09:08:34 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNAF8-0000Z7-Sz for ipsec@ietf.org; Thu, 28 Oct 2004 09:23:08 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6785A89830; Thu, 28 Oct 2004 16:08:30 +0300 (EEST) Message-ID: <4180EEE8.1070402@kolumbus.fi> Date: Thu, 28 Oct 2004 16:06:48 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com, ynir@checkpoint.com Subject: Re: [Ipsec] Reauthentication in IKEv2 References: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >>The missing piece is a way for the gateway to inform the client >>that the client needs to re-authenticate. I think this draft >>solves this issue, but when I first published it, there was >>little interest in the WG. I guess not many see gateway- >>controlled (or periodic) re-authentication as important. If >>you feel differently, please let me know. >> >>http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt > > > Yoav, I think this is an important issue, and the approach > presented in your draft is a good and simple way to solve it. > Please continue work towards publishing this as an RFC! I support this draft too. Or maybe not the exact details (see below) but I'd like to have this functionality. Why would "please re-authenticate now" notification not be simpler than a lifetime scheme? It would also support other re-authentication policies than time-based ones... --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 09:32:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11659 for ; Thu, 28 Oct 2004 09:32:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAMm-0004Bv-JM; Thu, 28 Oct 2004 09:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAHy-0003M1-IA for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 09:26: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 JAA11266 for ; Thu, 28 Oct 2004 09:26:01 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNAW2-0000wx-He for ipsec@ietf.org; Thu, 28 Oct 2004 09:40:36 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i9SDPNj15976; Thu, 28 Oct 2004 15:25:23 +0200 (IST) In-Reply-To: <4180EEE8.1070402@kolumbus.fi> References: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> <4180EEE8.1070402@kolumbus.fi> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <09E0193E-28E5-11D9-AE0F-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 15:26:56 +0200 To: Jari Arkko X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The reason I prefer a lifetime scheme to an "re-auth now" scheme is that re-authentication takes time. When one peer tells the other to re-authenticate "now", it means that it will not accept any informational or create-chile-sa exchanges until the peer runs another initial exchange. It might even mean that traffic will be blocked. Take for example the case of SecurID. A client for a SecurID user needs to show the user a dialog box, the user needs to find her token, type in the PIN, type in the temporary password and click the "re-auth" button. All this can take many many seconds, certainly long enough for TCP connections to break. This is why I prefer to let the client know in advance when re-authentication will be required. The gateway has enough leeway to tell the client to re-authenticate within a short time (section 2: "The AUTH_LIFETIME notification ... MAY be sent by the original Responder at any time"). So while it may be reasonable to say "authenticate within 1 minute", I don't think it's nice to say "you're blocked until you re-authenticate" Please let me know what you think, as expiry time is just around the corner :-) Yoav On Oct 28, 2004, at 3:06 PM, Jari Arkko wrote: > Pasi.Eronen@nokia.com wrote: > >>> The missing piece is a way for the gateway to inform the client that >>> the client needs to re-authenticate. I think this draft solves this >>> issue, but when I first published it, there was little interest in >>> the WG. I guess not many see gateway- >>> controlled (or periodic) re-authentication as important. If you feel >>> differently, please let me know. >>> >>> http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt >> Yoav, I think this is an important issue, and the approach >> presented in your draft is a good and simple way to solve it. Please >> continue work towards publishing this as an RFC! > > I support this draft too. Or maybe not the exact details > (see below) but I'd like to have this functionality. > > Why would "please re-authenticate now" notification > not be simpler than a lifetime scheme? It would also > support other re-authentication policies than time-based > ones... > > --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 09:41:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12449 for ; Thu, 28 Oct 2004 09:41:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAN7-0004GM-Gq; Thu, 28 Oct 2004 09:31:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAK5-0003hH-TK for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 09:28:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11349 for ; Thu, 28 Oct 2004 09:28:13 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNAY9-0000z4-VF for ipsec@ietf.org; Thu, 28 Oct 2004 09:42:47 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3421989830; Thu, 28 Oct 2004 16:28:11 +0300 (EEST) Message-ID: <4180F385.7070505@kolumbus.fi> Date: Thu, 28 Oct 2004 16:26:29 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: Policy lookups (Was: [Ipsec] Reauthentication in IKEv2) References: <125EA890549C8641A72F3809CB80DCCD16FD7B@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD7B@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Clearly it's already possible to e.g. use some value from the > certificate for policy lookup (instead of the IDi payload), > so in that sense, EAP doesn't change anything. Agreed. > And I don't think it matters whether the IP address comes from > RADIUS server or an internal pool maintained by the gateway: in > either case, it comes from somewhere "outside" the functionality > described in 2401bis. > > I guess the confusion is mostly because even with the addition > of PAD, 2401bis does not very clearly separate which parts of > SPD are used during per-packet processing in the kernel, and > which are only used during IKE negotiation. And the parts used > only by IKE are not that close to what actual implementations > do... > > (Of course, it's not even the intention of 2401bis to document > actual implementations, and it is explained that e.g. the > databases are only nominal, and not the way the information > has to be stored.) I agree with all of the above. But I still have a feeling that maybe we are missing something that the specifications should be saying. I think it is fine that implementations do not have to follow the nominal database implementation. And its great that implementations can do things beyond what has been stated in the RFCs. However, for the purposes of using IKEv2/2401bis for the FOO application one might wish to have a guarantee that implementations indeed are cabable of doing the things needed by FOO, and that the things are done in the same way by all implementations. For instance, that the same AAA protocol attributes are used in policy lookup; otherwise you would have to get the gateway and AAA server from the same vendor. An IKEv2 AAA Considerations RFC might be useful at some point in time. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 09:44:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12764 for ; Thu, 28 Oct 2004 09:44:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAXK-0006P6-Fm; Thu, 28 Oct 2004 09:41:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAOu-0004hV-6Z for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 09:33: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 JAA11689 for ; Thu, 28 Oct 2004 09:33:11 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNAcy-00014A-7r for ipsec@ietf.org; Thu, 28 Oct 2004 09:47:45 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SDWwl00221; Thu, 28 Oct 2004 16:32:58 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 16:32:47 +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 i9SDWlQW019372; Thu, 28 Oct 2004 16:32:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00VM3HOU; Thu, 28 Oct 2004 16:32:46 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 i9SDWda13297; Thu, 28 Oct 2004 16:32:39 +0300 (EET DST) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 16:32:35 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 16:32:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 16:32:35 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178396@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] Reauthentication in IKEv2 Thread-Index: AcS879AA3WVbKDS8RBKKz0nf0JmPHwAATdfg To: , X-OriginalArrivalTime: 28 Oct 2004 13:32:34.0980 (UTC) FILETIME=[95844E40:01C4BCF2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > > I support this draft too. Or maybe not the exact details > (see below) but I'd like to have this functionality. >=20 > Why would "please re-authenticate now" notification > not be simpler than a lifetime scheme? It would also > support other re-authentication policies than time-based > ones... Actually, the scheme in Yoav's draft supports other policies as=20 well: the responder can send a new AUTH_LIFETIME with a zero or small value to mean "please re-authenticate now". If the policy is time-based 99% of the time, then Yoav's scheme is IMHO simpler, since it doesn't need any extra messages (the lifetime can be sent in IKE_AUTH phase). But actually both approaches are very simple, so there's no big difference either... (BTW, knowing how much time is remaining allows the initiator=20 more options when to do the reauthentication; e.g. intelligent=20 UI that takes into account what the user is doing, or something like that.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 10:07:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14784 for ; Thu, 28 Oct 2004 10:07:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAsI-0003mD-33; Thu, 28 Oct 2004 10:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNAiZ-0000gO-Sw for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 09:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13447 for ; Thu, 28 Oct 2004 09:53:31 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNAwe-0001bS-63 for ipsec@ietf.org; Thu, 28 Oct 2004 10:08:05 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i9SDqwj23183; Thu, 28 Oct 2004 15:52:58 +0200 (IST) In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 15:54:31 +0200 To: X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I think that other than my draft there are several other ideas floating around like OCSP extensions, your own mobility and multi-homing, IKE over TCP, IKE over SCTP, hash-and-URL for PUT certificates, etc. Maybe instead of many small drafts, we need to join all these into one big "Optional Extensions for IKEv2" document, which will list all of these. On Oct 28, 2004, at 12:15 PM, wrote: >> http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt > > Yoav, I think this is an important issue, and the approach > presented in your draft is a good and simple way to solve it. > Please continue work towards publishing this as an RFC! > > WG chairs (& others), do you think that going for individual > submission for standards track would be the appropriate way > to proceed? Or would an informational document and/or making > this a WG item be better? > > Best regards, > Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 12:06:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07287 for ; Thu, 28 Oct 2004 12:06:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNC51-0005Xh-0t; Thu, 28 Oct 2004 11:20:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBZC-0002J1-Rm for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 10:47:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19537 for ; Thu, 28 Oct 2004 10:47:51 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBnC-0002uE-Vt for ipsec@ietf.org; Thu, 28 Oct 2004 11:02:26 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SElde27910; Thu, 28 Oct 2004 17:47:39 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 17:47:31 +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 i9SElVkk007711; Thu, 28 Oct 2004 17:47:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00aOrHj7; Thu, 28 Oct 2004 17:47:29 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 i9SElNa18344; Thu, 28 Oct 2004 17:47:24 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 17:47:13 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 17:47:14 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 17:47:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 17:47:13 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178398@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] Reauthentication in IKEv2 Thread-Index: AcS89bW9zlkOLdChT7qN4jmLLFNXxwAABzYA To: X-OriginalArrivalTime: 28 Oct 2004 14:47:14.0189 (UTC) FILETIME=[03555BD0:01C4BCFD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Yoav Nir writes: >=20 > I think that other than my draft there are several other=20 > ideas floating around like OCSP extensions, your own mobility=20 > and multi-homing, IKE over TCP, IKE over SCTP, hash-and-URL=20 > for PUT certificates, etc. >=20 > Maybe instead of many small drafts, we need to join all these=20 > into one big "Optional Extensions for IKEv2" document, which=20 > will list all of these. No, I don't think bundling them is a good idea.=20 If we have a good solution for a relevant problem (like your draft),=20 there's rough consensus on that, and there are no important=20 dependencies to/from other work, let's publish it. If we wait=20 for everything else IKEv2-related to be finished, it'll take several years before we have any RFCs. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 13:41:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29316 for ; Thu, 28 Oct 2004 13:41:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCkA-0002BU-Mn; Thu, 28 Oct 2004 12:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBjG-0005CE-TZ; Thu, 28 Oct 2004 10:58:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21008; Thu, 28 Oct 2004 10:58:17 -0400 (EDT) Message-Id: <200410281458.KAA21008@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 10:58:17 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-rfc2402bis-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-09.txt Pages : 34 Date : 2004-10-27 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-rfc2402bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110049.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Thu Oct 28 18:56:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04084 for ; Thu, 28 Oct 2004 18:56:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGF5-0003An-A8; Thu, 28 Oct 2004 15:47:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCp2-0006cp-N8 for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 12:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07507 for ; Thu, 28 Oct 2004 12:08:18 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CND38-0008Gg-7E for ipsec@ietf.org; Thu, 28 Oct 2004 12:22:54 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i9SG7ai25828; Thu, 28 Oct 2004 18:07:36 +0200 (IST) In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178398@esebe056.ntc.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD178398@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 Date: Thu, 28 Oct 2004 18:09:09 +0200 To: X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit OK. I'm all for publishing this, but I'm not sure that there really is a rough consensus. I will publish another draft when the IKEv2 RFC comes out, but I'm not sure how to proceed from there. On Oct 28, 2004, at 4:47 PM, wrote: > Yoav Nir writes: >> >> I think that other than my draft there are several other >> ideas floating around like OCSP extensions, your own mobility >> and multi-homing, IKE over TCP, IKE over SCTP, hash-and-URL >> for PUT certificates, etc. >> >> Maybe instead of many small drafts, we need to join all these >> into one big "Optional Extensions for IKEv2" document, which >> will list all of these. > > No, I don't think bundling them is a good idea. > > If we have a good solution for a relevant problem (like your draft), > there's rough consensus on that, and there are no important > dependencies to/from other work, let's publish it. If we wait > for everything else IKEv2-related to be finished, it'll take > several years before we have any RFCs. > > Best regards, > Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 18:57:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04578 for ; Thu, 28 Oct 2004 18:57:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGOU-0002c4-9L; Thu, 28 Oct 2004 15:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNDJy-0004Wv-Qe for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 12:40:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14418 for ; Thu, 28 Oct 2004 12:40:13 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNDY2-00029x-7g for ipsec@ietf.org; Thu, 28 Oct 2004 12:54:51 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D8DF289830; Thu, 28 Oct 2004 19:40:11 +0300 (EEST) Message-ID: <41812085.1090905@kolumbus.fi> Date: Thu, 28 Oct 2004 19:38:29 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Reauthentication in IKEv2 References: <125EA890549C8641A72F3809CB80DCCD178396@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178396@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Actually, the scheme in Yoav's draft supports other policies as > well: the responder can send a new AUTH_LIFETIME with a zero > or small value to mean "please re-authenticate now". Ok, I'm convinced. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 19:00:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05231 for ; Thu, 28 Oct 2004 19:00:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGSI-0001Xw-Fd; Thu, 28 Oct 2004 16:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNDtG-0004rn-PX for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 13:16: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 NAA23244 for ; Thu, 28 Oct 2004 13:16:44 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNE7M-0005CJ-IO for ipsec@ietf.org; Thu, 28 Oct 2004 13:31:22 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B39D389830; Thu, 28 Oct 2004 20:16:43 +0300 (EEST) Message-ID: <41812915.10809@kolumbus.fi> Date: Thu, 28 Oct 2004 20:15:01 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Reauthentication in IKEv2 References: <125EA890549C8641A72F3809CB80DCCD178398@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178398@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Yoav Nir writes: > >>I think that other than my draft there are several other >>ideas floating around like OCSP extensions, your own mobility >>and multi-homing, IKE over TCP, IKE over SCTP, hash-and-URL >>for PUT certificates, etc. >> >>Maybe instead of many small drafts, we need to join all these >>into one big "Optional Extensions for IKEv2" document, which >>will list all of these. > > > No, I don't think bundling them is a good idea. > > If we have a good solution for a relevant problem (like your draft), > there's rough consensus on that, and there are no important > dependencies to/from other work, let's publish it. If we wait > for everything else IKEv2-related to be finished, it'll take > several years before we have any RFCs. I agree with this. Small, well-focused extensions is the way to go. And I'd add your certificate-less server authentication with mutually authenticating EAP methods draft (draft-eronen-ipsec-ikev2-eap-auth-01.txt) to the list of good ideas to take forward. Mobility and multihoming is already being dealt with in a separate WG. If your draft and Yoav's draft could go forward somewhere then my highest priority items would be done. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 19:21:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08779 for ; Thu, 28 Oct 2004 19:21:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGcE-0008Kh-6B; Thu, 28 Oct 2004 16:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNFTg-00027W-ED for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 14:58:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16626 for ; Thu, 28 Oct 2004 14:58:27 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNFhm-0004ZQ-Vl for ipsec@ietf.org; Thu, 28 Oct 2004 15:13:04 -0400 Received: (qmail 6458 invoked by uid 0); 28 Oct 2004 18:58:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.11) by woodstock.binhost.com with SMTP; 28 Oct 2004 18:58:19 -0000 Message-Id: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 28 Oct 2004 14:58:19 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ipsec] AES Algorithm Negotiation in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear IPsec WG: We have documents that specify three modes of AES. They are AES-CBC, AES-CTR, AES-CCM, and AES-GCM. In each case, these documents register an algorithm identifier with IANA. Since only one of these has achieved RFC status so far, only AES-CBC actually has a number yet: AES-CBC has been assigned number 7 [see RFC 3602]. Since the AES supports three key lengths, the Key Length attribute must be specified in the IKE Phase 2 exchange. Of course, the Key Length attribute value can be either 128, 192, or 256. AES is the only commonly-implemented algorithm that requires key length negotiation, and there have been reports of interoperability problems in this area. Two of the AES modes (AES-CCM and AES-GCM) provide confidentiality and integrity. Both of these AES modes offer more than one integrity check value (ICV) size. How do we want to negotiate the ICV size for a particular security association. I see three choices. First, we could do it the same way that we do AES key size. That is, IKE could negotiate another algorithm-specific value. Given the interoperability issues with key length, I am not sure this is the right approach. Second, we could assign an algorithm identifier for each ICV size. This approach leads to many IANA registry entries, but no new IKE code is needed to support any of the AES modes. Third, we could decide that the negotiation of key length was also a mistake. This approach would lead to three times as many IANA registry entries as the previous approach, but it might be a quick solution to the interoperability concerns. I would like to hear from the working group. What is the best way forward. Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 28 22:57:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28777 for ; Thu, 28 Oct 2004 22:57:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMCp-0002ZW-Kd; Thu, 28 Oct 2004 22:09:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJjb-0006sv-PG for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 19:31:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11580 for ; Thu, 28 Oct 2004 19:31:09 -0400 (EDT) Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJxl-0003l6-K0 for ipsec@ietf.org; Thu, 28 Oct 2004 19:45:50 -0400 Received: from [192.168.0.2] ([217.132.194.144]) by mxout5.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6B001BSIN22V@mxout5.netvision.net.il> for ipsec@ietf.org; Fri, 29 Oct 2004 01:30:38 +0200 (IST) Date: Fri, 29 Oct 2004 01:30:36 +0200 From: Yoav Nir Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE In-reply-to: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> To: ipsec Message-id: <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7BIT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT IMO the keylength attribute is well-specified, at least in the IKEv2 document. If there are going to be interoperability issues then it means that somebody is not implementing it correctly. I would go with option #1. If only AES-CBC has a number, I'm wondering why the cryptographic suites document went with AES-CTR? On 28/10/2004, at 20:58, Russ Housley wrote: > Dear IPsec WG: > > We have documents that specify three modes of AES. They are AES-CBC, > AES-CTR, AES-CCM, and AES-GCM. In each case, these documents register > an algorithm identifier with IANA. Since only one of these has > achieved RFC status so far, only AES-CBC actually has a number yet: > > AES-CBC has been assigned number 7 [see RFC 3602]. > > Since the AES supports three key lengths, the Key Length attribute > must be specified in the IKE Phase 2 exchange. Of course, the Key > Length attribute value can be either 128, 192, or 256. > > AES is the only commonly-implemented algorithm that requires key > length negotiation, and there have been reports of interoperability > problems in this area. > > Two of the AES modes (AES-CCM and AES-GCM) provide confidentiality and > integrity. Both of these AES modes offer more than one integrity > check value (ICV) size. How do we want to negotiate the ICV size for > a particular security association. I see three choices. > > First, we could do it the same way that we do AES key size. That is, > IKE could negotiate another algorithm-specific value. Given the > interoperability issues with key length, I am not sure this is the > right approach. > > Second, we could assign an algorithm identifier for each ICV size. > This approach leads to many IANA registry entries, but no new IKE code > is needed to support any of the AES modes. > > Third, we could decide that the negotiation of key length was also a > mistake. This approach would lead to three times as many IANA > registry entries as the previous approach, but it might be a quick > solution to the interoperability concerns. > > I would like to hear from the working group. What is the best way > forward. > > 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 Thu Oct 28 23:46:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04881 for ; Thu, 28 Oct 2004 23:46:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNNTl-0005PV-6D; Thu, 28 Oct 2004 23:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNNCD-0006x8-JH for ipsec@megatron.ietf.org; Thu, 28 Oct 2004 23:12:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01356 for ; Thu, 28 Oct 2004 23:12:56 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNQP-0002IU-VQ for ipsec@ietf.org; Thu, 28 Oct 2004 23:27:38 -0400 Received: from [165.227.249.219] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T3CeMK020033 for ; Thu, 28 Oct 2004 20:12:41 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> Date: Thu, 28 Oct 2004 20:12:49 -0700 To: IPsec WG From: Paul Hoffman / VPNC Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 1.2 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 1:30 AM +0200 10/29/04, Yoav Nir wrote: >IMO the keylength attribute is well-specified, at least in the IKEv2 >document. If there are going to be interoperability issues then it >means that somebody is not implementing it correctly. Of course, but that is what has happened in a couple of cases. We have been fortunate in our AES interop testing at VPNC to not have any systems in the lab be mis-implemented, but I have heard from at least two different vendors that they didn't get it right the first time. >I would go with option #1. Inventing a new algorithm-specific identifier seems silly from an interop standpoint, given that we have essentially no experience with it in common deployments. It seems like the table in #2 would be a lot easier for implementers to get right the first time. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 02:05:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18044 for ; Fri, 29 Oct 2004 02:05:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNPqd-00067a-DU; Fri, 29 Oct 2004 02: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 1CNPXE-0003hL-BG for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 01:42: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 BAA11196 for ; Fri, 29 Oct 2004 01:42:47 -0400 (EDT) Received: from cp.64translator.com ([202.214.123.2] helo=senegal.64translator.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPlQ-0005aG-DY for ipsec@ietf.org; Fri, 29 Oct 2004 01:57:29 -0400 Received: from localhost (localhost [IPv6:::1]) by senegal.64translator.com (8.12.11/8.12.11) with SMTP id i9T5gFQR000853 for ; Fri, 29 Oct 2004 14:42:15 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Date: Fri, 29 Oct 2004 14:42:15 +0900 From: Nobumichi Ozoe To: Message-Id: <20041029144215.214f07ec.Nobumichi.Ozoe@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [Ipsec] 6th TAHI IPv6 Interoperability Test Event - 24 - 28 January 2005, Chiba, Japan X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear All, TAHI Projcet is organizing its 6th TAHI IPv6 Interoperability Test Event. The event will be held from 24th - 28th January 2005 at the Makuhari messe of Chiba Japan. Registration will be avairable from 17 November 2004 at: http://www.tahi.org/inop/6thinterop.html Deadline to register is 31 December 2004 This time we will provide the following tests: o Conformance test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, IKE for IPv6, SNMP for IPv6 SIP, IPv6 Core Protocol, IPsec, MLDv1, Default Address Selection, Default Router Preference .... o Interoperability test: IPv6 Ready Logo Phase-2, Phase-1, MIPv6, NEMO SIP, IPv6 Core Protocol, IPsec, IKE, Prefix Delegation, MLDv2 .... For more details, please visit our web site. * TAHI Project Home Page http://www.tahi.org/ * 6th TAHI IPv6 Interoperability Test Event Announce Page http://www.tahi.org/inop/6thinterop.html #I'm sorry if you have already received this mail. Regards, -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 03:00:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00203 for ; Fri, 29 Oct 2004 03:00:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQaN-0007ME-P7; Fri, 29 Oct 2004 02:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNQPr-0007LN-9v for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 02:39:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29312 for ; Fri, 29 Oct 2004 02:39:13 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQe3-0006Xz-LB for ipsec@ietf.org; Fri, 29 Oct 2004 02:53:56 -0400 Received: by wproxy.gmail.com with SMTP id 50so984349wri for ; Thu, 28 Oct 2004 23:38:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=RLZ/5g0DZIWwLd5Wn8PffKruTG7bKkGequPvEtAj5oFWz+phR3xsUFzzkqsc82cqATGVnMma21FYfPNSlPw9CGUD2osZanzW90Y2xBBkNcFZgp7jx5fm+dSoCOvY3wCZzK0CFshm5zy/Nkj1GOiPrn0XhpMct1ZAOfrP9zN4Y6k= Received: by 10.38.171.63 with SMTP id t63mr110067rne; Thu, 28 Oct 2004 23:38:40 -0700 (PDT) Received: by 10.38.171.37 with HTTP; Thu, 28 Oct 2004 23:38:40 -0700 (PDT) Message-ID: <67589b6f04102823385a66d036@mail.gmail.com> Date: Fri, 29 Oct 2004 12:08:40 +0530 From: Rahul Vaidya To: ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Doubts regarding SA's formed suring IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rahul Vaidya List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, I have some doubts regarding SA's formed during IKEv2. 1. In IKE_SA_INIT phase, is a bi-directional IKE SA formed (Bidirection meaning same properties for inbound and outbound traffic at one end) 2. In IKE_AUTH phases, is a bi-directional ESP/AH SA formed or a pair of IPSEC SA's (different properties for inbound and outbound traffice at one end) formed? (Considering H1 and H2 as hosts between which IKE is being negotiated, does it mean that, during IKE_AUTH, IPSEC SA's are formed simultaneously from H1 to H2 and also from H2 to H1, assuming H1 is the initiator.) i. If a pair of SA's are being formed during IKE_AUTH, Can they have different "SA algorithms etc" in each direction. (Like say H1 to H2 I want ESP. And H2 to H1 I want only authentication, i.e AH.) Is it possible? ii. Also is it possible to do create a uni-directional IPSec SA in either IKE_AUTH or Create_Child SA? Thanks in advance, Regards, Rahul Vaidya. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 05:27:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11186 for ; Fri, 29 Oct 2004 05:27:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSvv-0001z1-I5; Fri, 29 Oct 2004 05:20:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSQ9-0003cW-Gx for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 04:47: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 EAA08598 for ; Fri, 29 Oct 2004 04:47:39 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSeO-00013T-EV for ipsec@ietf.org; Fri, 29 Oct 2004 05:02:25 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i9T8lQad002558 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 29 Oct 2004 11:47:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i9T8lPsS002555; Fri, 29 Oct 2004 11:47:25 +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: <16770.925.470265.268813@fireball.kivinen.iki.fi> Date: Fri, 29 Oct 2004 11:47:25 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] Reauthentication in IKEv2 In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 13 min X-Total-Time: 15 min X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > > http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-00.txt > > Yoav, I think this is an important issue, and the approach > presented in your draft is a good and simple way to solve it. > Please continue work towards publishing this as an RFC! I think it would be much more simplier to siply send one informational message from the gateway when he wants the client to redo authentication, and if client does not finish reauthentication within some server specified timeframe then server will disconnect the connection. We do not have negotiated lifetimes in the IKEv2, so why add them now? You could already use the AUTH_LIFETIME specified in the draft that way, but I think that the lifetime parameter simply adds complexity and should be left out. The server needs to still keep the timers and verify that the client has done the authentication on time, so for the server he could simply keep timer and send the REAUTH_NOW notification when reauthentication is required. Now client also must keep the timer and start authentication before the given time. If server would simply send the REAUTHENTICATE_NOW notifies, then client does not keep the timers to do this. Also why cannot the SAi1 change? > WG chairs (& others), do you think that going for individual > submission for standards track would be the appropriate way > to proceed? Or would an informational document and/or making > this a WG item be better? When this was last time discussed here in the list there was not much support for this. There were few emails and most of those argue either the method how to do it, or the need for this. At least I didn't see enough support for this, in the list, so this could really be a WG item. I think this should propably be postponed to the IKEv2 extensions WG (I assume someone will someday create one), just like the draft-eronen-ipsec-ikev2-eap-auth-02.txt... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 05:52:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12982 for ; Fri, 29 Oct 2004 05:52:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNT1k-0007kH-KU; Fri, 29 Oct 2004 05:26:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSnX-00071u-LV for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 05:11:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10042 for ; Fri, 29 Oct 2004 05:11:49 -0400 (EDT) From: Mika.Joutsenvirta@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNT1m-0001Sr-3H for ipsec@ietf.org; Fri, 29 Oct 2004 05:26:35 -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 i9T9Bc325065; Fri, 29 Oct 2004 12:11:38 +0300 (EET DST) X-Scanned: Fri, 29 Oct 2004 12:11:28 +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 i9T9BSkX020888; Fri, 29 Oct 2004 12:11:28 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00hbAnhv; Fri, 29 Oct 2004 12:11:27 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 i9T9BJa14958; Fri, 29 Oct 2004 12:11:19 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 12:11:17 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 12:11:17 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 12:11:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Reauthentication in IKEv2 Date: Fri, 29 Oct 2004 12:11:16 +0300 Message-ID: <8AA62C0ABD31B544993F7592D885280615CA9F@trebe051.ntc.nokia.com> Thread-Topic: [Ipsec] Reauthentication in IKEv2 Thread-Index: AcS9QhrF27b5MtcDRd+wq4euu3r0ggAU9OuQ To: , X-OriginalArrivalTime: 29 Oct 2004 09:11:16.0813 (UTC) FILETIME=[3F039FD0:01C4BD97] X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, 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 Content-Transfer-Encoding: quoted-printable I also support idea of having just small extensions. Both of the drafts mentioned here makes sense and I certainly would like to see some progress with draft-eronen-ipsec-ikev2-eap-auth-01.txt. Mika > -----Original Message----- > From: ipsec-bounces@ietf.org=20 > [mailto:ipsec-bounces@ietf.org]On Behalf Of > ext Jari Arkko > Sent: 28 October, 2004 20:15 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: ipsec@ietf.org; ynir@checkpoint.com > Subject: Re: [Ipsec] Reauthentication in IKEv2 >=20 >=20 > Pasi.Eronen@nokia.com wrote: > > Yoav Nir writes: > >=20 > >>I think that other than my draft there are several other=20 > >>ideas floating around like OCSP extensions, your own mobility=20 > >>and multi-homing, IKE over TCP, IKE over SCTP, hash-and-URL=20 > >>for PUT certificates, etc. > >> > >>Maybe instead of many small drafts, we need to join all these=20 > >>into one big "Optional Extensions for IKEv2" document, which=20 > >>will list all of these. > >=20 > >=20 > > No, I don't think bundling them is a good idea.=20 > >=20 > > If we have a good solution for a relevant problem (like=20 > your draft),=20 > > there's rough consensus on that, and there are no important=20 > > dependencies to/from other work, let's publish it. If we wait=20 > > for everything else IKEv2-related to be finished, it'll take > > several years before we have any RFCs. >=20 > I agree with this. Small, well-focused extensions is the > way to go. >=20 > And I'd add your certificate-less server authentication > with mutually authenticating EAP methods draft > (draft-eronen-ipsec-ikev2-eap-auth-01.txt) to the list > of good ideas to take forward. Mobility and multihoming > is already being dealt with in a separate WG. If your > draft and Yoav's draft could go forward somewhere then > my highest priority items would be done. >=20 > --Jari >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 05:56:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13370 for ; Fri, 29 Oct 2004 05:56:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNT2O-0008PY-RX; Fri, 29 Oct 2004 05:27:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSt2-0000dA-G5 for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 05:17: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 FAA10465 for ; Fri, 29 Oct 2004 05:17:30 -0400 (EDT) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNT7H-0001am-Nb for ipsec@ietf.org; Fri, 29 Oct 2004 05:32:16 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i9T9HPkn002880 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 29 Oct 2004 12:17:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i9T9HPvF002877; Fri, 29 Oct 2004 12:17:25 +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: <16770.2724.997837.665198@fireball.kivinen.iki.fi> Date: Fri, 29 Oct 2004 12:17:24 +0300 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 In-Reply-To: <09E0193E-28E5-11D9-AE0F-000A95834BAA@checkpoint.com> References: <125EA890549C8641A72F3809CB80DCCD16FD76@esebe056.ntc.nokia.com> <4180EEE8.1070402@kolumbus.fi> <09E0193E-28E5-11D9-AE0F-000A95834BAA@checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Jari Arkko , Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > The reason I prefer a lifetime scheme to an "re-auth now" scheme is > that re-authentication takes time. So what? Server also know what it is asking, so it can set its own timers so that client have enough time to do the authentication. I.e for the RSA certificate authentication it could give 2 minutes, and for SecurID authentication it could give 5 minutes. > When one peer tells the other to re-authenticate "now", it means that > it will not accept any informational or create-chile-sa exchanges until > the peer runs another initial exchange. It might even mean that Why would it do that? The REAUTHENTICATE_NOW message means that start reauthentication as soon as possible, but old IKE SA will stay active and working until it is deleted. You can still create new child sa on it and so on, but server will delete it quiet soon, so better create new IKE SA... > traffic will be blocked. Take for example the case of SecurID. A > client for a SecurID user needs to show the user a dialog box, the user > needs to find her token, type in the PIN, type in the temporary > password and click the "re-auth" button. All this can take many many > seconds, certainly long enough for TCP connections to break. If you implement your client that way, then it is your problem. Nowhere we mentioned that the old IKE SA or old IPsec SAs would stop working. They continue work until they are explicitly deleted. > This is why I prefer to let the client know in advance when > re-authentication will be required. The gateway has enough leeway to > tell the client to re-authenticate within a short time (section 2: "The > AUTH_LIFETIME notification ... MAY be sent by the original Responder at > any time"). So while it may be reasonable to say "authenticate within > 1 minute", I don't think it's nice to say "you're blocked until you > re-authenticate" I think the REAUTHENTICATE_NOW means exactly that: reauthenticate as soon as possible. The server will never BLOCK any traffic, it will, simply send the delete to the IKE SA after it has decided that client has had enough time to do the reauthentication. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 06:02:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13986 for ; Fri, 29 Oct 2004 06:02:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNTBM-00048b-UI; Fri, 29 Oct 2004 05:36:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSyq-0005Mm-Oi for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 05: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 FAA10867 for ; Fri, 29 Oct 2004 05:23:30 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNTD5-0001i5-CX for ipsec@ietf.org; Fri, 29 Oct 2004 05:38:16 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9T9MtQ10715; Fri, 29 Oct 2004 11:22:55 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9T9MsSj035641; Fri, 29 Oct 2004 11:22:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410290922.i9T9MsSj035641@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Russ Housley Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE In-reply-to: Your message of Thu, 28 Oct 2004 14:58:19 EDT. <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> Date: Fri, 29 Oct 2004 11:22:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: We have documents that specify three modes of AES. They are AES-CBC, ^^^^^ ? AES-CTR, AES-CCM, and AES-GCM. Third, we could decide that the negotiation of key length was also a mistake. This approach would lead to three times as many IANA registry entries as the previous approach, but it might be a quick solution to the interoperability concerns. => transform IDs are on 16 bits (1-1023 for IANA): I am in favor of this third solution. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 09:35:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28480 for ; Fri, 29 Oct 2004 09:35:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWhj-0007dQ-Di; Fri, 29 Oct 2004 09:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWZ3-0000r8-0P for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 09:13:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27201 for ; Fri, 29 Oct 2004 09:13:07 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWnK-0006fQ-SH for ipsec@ietf.org; Fri, 29 Oct 2004 09:27:55 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i9TD7Rd01279 for ; Fri, 29 Oct 2004 09:07:28 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i9TD9x5I010246 for ; Fri, 29 Oct 2004 09:09:59 -0400 (EDT) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlnaO9t; Fri, 29 Oct 04 09:09:51 -0400 Date: Fri, 29 Oct 2004 06:12:56 -0800 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cfftvdpprxvdywokjkro" X-Spam-Score: 1.2 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Thanks :) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------cfftvdpprxvdywokjkro Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------cfftvdpprxvdywokjkro Content-Type: text/html; name="price.cpl.htm" Content-Disposition: attachment; filename="price.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: price.cpl
Virus name: W32/Bagle.bb@MM

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

----------cfftvdpprxvdywokjkro Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------cfftvdpprxvdywokjkro-- From ipsec-bounces@ietf.org Fri Oct 29 11:07:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07695 for ; Fri, 29 Oct 2004 11:07:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNY7w-0001HD-7U; Fri, 29 Oct 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 1CNXtJ-0002Sg-42 for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 10:38:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05500 for ; Fri, 29 Oct 2004 10:38:06 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNY7b-0000Kp-BT for ipsec@ietf.org; Fri, 29 Oct 2004 10:52:55 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9TEbv307458; Fri, 29 Oct 2004 17:37:57 +0300 (EET DST) X-Scanned: Fri, 29 Oct 2004 17:37:29 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9TEbTng007811; Fri, 29 Oct 2004 17:37:29 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00LLTahN; Fri, 29 Oct 2004 17:30:46 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9TEUkS25737; Fri, 29 Oct 2004 17:30:46 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 15:28:31 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 15:28:27 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 15:28:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Reauthentication in IKEv2 Date: Fri, 29 Oct 2004 15:28:25 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] Reauthentication in IKEv2 Thread-Index: AcS9lxNltSKpSK4hTJ2Ky83MmlJh/wADpImw To: X-OriginalArrivalTime: 29 Oct 2004 12:28:25.0944 (UTC) FILETIME=[C9B9C580:01C4BDB2] X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > > I think it would be much more simplier to siply send one > informational message from the gateway when he wants the > client to redo authentication, and if client does not finish > reauthentication within some server specified timeframe then > server will disconnect the connection. Yes, but the client has more knowledge about the situation... =20 E.g., if I have a long download ongoing, and I'm leaving for=20 lunch, I could check how much time is remaining before the=20 next reauthentication (instead of always reauthenticating "just in case", or hoping for the best). And sending the lifetime means one message exchange less in >99% of the cases, so it's IMHO the simpler of the two alternatives (but I guess we disagree here :-). > We do not have negotiated lifetimes in the IKEv2, so why add > them now? You could already use the AUTH_LIFETIME specified > in the draft that way, but I think that the lifetime parameter > simply adds complexity and should be left out. The server > needs to still keep the timers and verify that the client has > done the authentication on time, so for the server he could > simply keep timer and send the REAUTH_NOW notification when > reauthentication is required. Normal rekeying can be initiated by either end, and does not require user interaction, so the peers can have their own policies without any need for negotiation. But IMHO here making the gateway's policy visible to the client would (in some circumstances) provide benefits to the end user. > Now client also must keep the timer and start authentication > before the given time. If server would simply send the > REAUTHENTICATE_NOW notifies, then client does not keep the > timers to do this. Unless the client also has a policy about reauthenticating the server; then both parties need timers. > > At least I didn't see enough support for this, in the list, so > this could really be a WG item. I think this should propably > be postponed to the IKEv2 extensions WG (I assume someone will > someday create one), just like the > draft-eronen-ipsec-ikev2-eap-auth-02.txt... Are you against publishing them as individual submissions? (Taking into account that it looks like several vendors will=20 ship something like this in 2005, so the alternative is=20 vendor-specific extensions.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 11:32:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09456 for ; Fri, 29 Oct 2004 11:32:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNYgX-0007G6-8r; Fri, 29 Oct 2004 11:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNYSb-0006El-DY for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 11:14: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 LAA08286 for ; Fri, 29 Oct 2004 11:14:33 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNYgs-0001Cl-7N for ipsec@ietf.org; Fri, 29 Oct 2004 11:29:22 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i9TFE12B021488 for ; Fri, 29 Oct 2004 11:14:02 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i9TFE1qn021483; Fri, 29 Oct 2004 11:14:01 -0400 Received: from PKONING.equallogic.com ([172.16.2.97]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Oct 2004 11:14:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16770.24109.878000.862040@gargle.gargle.HOWL> Date: Fri, 29 Oct 2004 11:13:49 -0400 From: Paul Koning To: ynir@netvision.net.il Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 29 Oct 2004 15:14:01.0517 (UTC) FILETIME=[EBC9E5D0:01C4BDC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Yoav" == Yoav Nir writes: Yoav> IMO the keylength attribute is well-specified, at least in the Yoav> IKEv2 document. If there are going to be interoperability Yoav> issues then it means that somebody is not implementing it Yoav> correctly. Yoav> I would go with option #1. I agree. Implementing little protocol details like the key length element isn't rocket science. I don't see any good reason to hack up the spec to accommodate buggy implementations. For one thing, there's no reason to believe it will help. What's there now is the right approach. Similarly, ICV length for the combined algorithms should be another parameter just like the key length -- not encoded in the algorithm ID. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 14:45:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23003 for ; Fri, 29 Oct 2004 14:45:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbZt-0001xW-Ry; Fri, 29 Oct 2004 14:34:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbWL-0008Qt-Ty for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 14:30: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 OAA22046 for ; Fri, 29 Oct 2004 14:30:39 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbjQ-0005GN-DB for ipsec@ietf.org; Fri, 29 Oct 2004 14:44:13 -0400 Received: from above.proper.com ([208.184.76.39]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CNbFk-0003On-Iu for ipsec@ietf.org; Fri, 29 Oct 2004 14:13:32 -0400 Received: from [165.227.249.219] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TIC8op021049 for ; Fri, 29 Oct 2004 11:12:09 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16770.24109.878000.862040@gargle.gargle.HOWL> References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> <16770.24109.878000.862040@gargle.gargle.HOWL> Date: Fri, 29 Oct 2004 11:11:42 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:13 AM -0400 10/29/04, Paul Koning wrote: >Implementing little protocol details like the key length element isn't >rocket science. I don't see any good reason to hack up the spec to >accommodate buggy implementations. There is no spec hacking here: the spec explicitly allows for both algorithm IDs and parameters. > For one thing, there's no reason >to believe it will help. What's there now is the right approach. There is nothing in 2409 about ICV length. >Similarly, ICV length for the combined algorithms should be another >parameter just like the key length -- not encoded in the algorithm >ID. Let me push back on this and ask for real-world implementers: do you agree here? That it would be better to create a new algorithm-specific parameter and use the current parameter system rather than two additional algorithms IDs for CCM and zero additional algorithm IDs for GCM? If it is so important that we add new ICV parameters, why wasn't this discussed in any of the rounds of either protocols, even in the WG and IETF last calls? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 15:48:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29960 for ; Fri, 29 Oct 2004 15:48:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcM7-0000Qj-NE; Fri, 29 Oct 2004 15:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcIY-0002QQ-5u for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 15:20:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27182 for ; Fri, 29 Oct 2004 15:20:28 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNcWr-0006Ua-7G for ipsec@ietf.org; Fri, 29 Oct 2004 15:35:19 -0400 Received: from SriniSony (dhcp-50.intoto.com [10.1.5.50]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id i9TJMdRQ030738; Fri, 29 Oct 2004 12:22:43 -0700 Message-Id: <200410291922.i9TJMdRQ030738@intotoinc.com> From: "Srinivasa Rao Addepalli" To: "'Jyothi'" , Subject: RE: [Ipsec] Reauthentication in IKEv2 Date: Fri, 29 Oct 2004 12:20:18 -0700 Organization: Intoto Inc MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcS8o72bqesi/2NVQwS3HFlUb1pCmwBRptRw In-Reply-To: <5.1.0.14.0.20041028090205.0304d710@172.16.1.10> X-Spam-Score: 0.2 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 X-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="===============0229030354==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0229030354== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E6_01C4BDB1.A70E4D90" This is a multi-part message in MIME format. ------=_NextPart_000_03E6_01C4BDB1.A70E4D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I have some questions regarding the Reauthentication in IKEv2. 1. CREATE_CHILD_SA exchange is supported. In this when the IKE SA lifetime is completed, we use CREATE_CHILD_SA exchange and form new IKE SA keys. Is it required to reauthenticate the peer may be after some time??? > I would suggest to leave the initiation of re-authentication to external entity (outside IKE). If reauthentication is required, in case of EAP authentication, it says that CLIENT may use the EAP Fast reauthentication ID in IKE exchange. -- Yes That is right. In this case IKE policy lookup may fail, if we are searching with the received identity. If reauthentication is required, what is the best way to proceed?? May be the responder has to maintain some mapping between policy identity and EAP negotiated identity. >I would assume that EAP methods, following NAI format for IDs would have same 'realm' name for permanent and fast re-authentication identities. 'realm' can be used to select the responder IKE policy. At the configuration time, Initiators (Clients) should have prior knowledge that the responder identifies the IKE policy based on partial information. Only then, it should honor EAP client to overwrite IDi value. If the responder identifies the IKE policy on full information, Initiator should always use the same Identification always. In this case, there is a possibility of full re-authentication by EAP. But, in general, I would assume that, EAP is used in remote access scenarios and 'realm' specific policy search would be used. 2. CREATE_CHILD_SA exchange is not supported In this case, peer will always authenticate. If EAP authentication is used, do we have to go for EAP re-authentication??? > Awaiting your responses. Thanks in advance, Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_03E6_01C4BDB1.A70E4D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Hi all,

 

I have some questions regarding the Reauthentication in = IKEv2.

 

1. CREATE_CHILD_SA exchange is = supported.

 

In this when the IKE SA lifetime is completed, we use = CREATE_CHILD_SA

exchange and form new IKE SA keys.

 

Is it required to reauthenticate the peer may be after some = time???

 

> I would suggest to leave the initiation of re-authentication to external entity (outside = IKE).

 

If reauthentication is required, in case of EAP authentication, = it says

that CLIENT may use the EAP Fast reauthentication ID in IKE = exchange.

 

-- Yes That is = right.

 

In this case IKE policy lookup may fail, if we are searching = with the

received identity.

 

If reauthentication is required, what is the best way to = proceed??

 

May be the responder has to maintain some mapping between policy identity

and EAP negotiated identity.

 

>I would assume that EAP methods, = following NAI format for IDs would have same ‘realm’ name for permanent = and fast re-authentication identities. ‘realm’ can be used to select = the responder IKE policy. At the configuration time, Initiators (Clients) = should have prior knowledge that the responder identifies the IKE policy based = on partial information. Only then, it should honor EAP client to overwrite = IDi value.  If the responder identifies the IKE policy on full information, = Initiator should always use the same Identification always. In this case, there is = a possibility of full re-authentication by EAP. But, in general, I would = assume that, EAP is used in remote access scenarios and ‘realm’ = specific policy search would be used.

 

 

 

 

2. CREATE_CHILD_SA exchange is not = supported

 

In this case, peer will always = authenticate.

 

If EAP authentication is used, do we have to go for EAP re-authentication???

 

> =

 

Awaiting your responses.

 

Thanks in advance,

Jyothi

 

 

_______________________________________________=

Ipsec mailing list

Ipsec@ietf.org

https://www1.ietf.org/mailman/listinfo/ipsec

------=_NextPart_000_03E6_01C4BDB1.A70E4D90-- --===============0229030354== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0229030354==-- From ipsec-bounces@ietf.org Fri Oct 29 16:19:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03362 for ; Fri, 29 Oct 2004 16:19:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcla-00052X-OZ; Fri, 29 Oct 2004 15:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNcRt-0004YK-E3 for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 15:30:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28357 for ; Fri, 29 Oct 2004 15:30:07 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNcgB-0006k5-3L for ipsec@ietf.org; Fri, 29 Oct 2004 15:44:58 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i9TJTW2B006887 for ; Fri, 29 Oct 2004 15:29:32 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i9TJTWqn006882; Fri, 29 Oct 2004 15:29:32 -0400 Received: from PKONING.equallogic.com ([172.16.2.97]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Oct 2004 15:29:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16770.39440.480000.71261@gargle.gargle.HOWL> Date: Fri, 29 Oct 2004 15:29:20 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> <16770.24109.878000.862040@gargle.gargle.HOWL> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 29 Oct 2004 19:29:32.0390 (UTC) FILETIME=[9DB37860:01C4BDED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Paul" == Paul Hoffman > writes: Paul> At 11:13 AM -0400 10/29/04, Paul Koning wrote: >> Implementing little protocol details like the key length element >> isn't rocket science. I don't see any good reason to hack up the >> spec to accommodate buggy implementations. Paul> There is no spec hacking here: the spec explicitly allows for Paul> both algorithm IDs and parameters. Sure, but the design all along has been that the algorithm ID selects the algorithm, and parameters carry algorithm variables such as key length. >> For one thing, there's no reason to believe it will help. What's >> there now is the right approach. Paul> There is nothing in 2409 about ICV length. No, but key length has been around for a while. >> Similarly, ICV length for the combined algorithms should be >> another parameter just like the key length -- not encoded in the >> algorithm ID. Paul> Let me push back on this and ask for real-world implementers: Paul> do you agree here? That it would be better to create a new Paul> algorithm-specific parameter and use the current parameter Paul> system rather than two additional algorithms IDs for CCM and Paul> zero additional algorithm IDs for GCM? Paul> If it is so important that we add new ICV parameters, why Paul> wasn't this discussed in any of the rounds of either protocols, Paul> even in the WG and IETF last calls? If the issue is that it's too late to add the missing parameter, and variable ICV length is needed, then I guess using multiple algorithm IDs is a sensible workaround. In that case, I would find either approach acceptable. That wasn't my main point. My main point was about the key length parameter. As an implementer, I find it perfectly straightforward to deal with a key length parameter for algorithms that have a use for one. It sounded like the issue with key length was that some implementations didn't implement it right. Ok, so fix them, what's the big deal? If we establish a precedent of changing the spec rather than the implementation when an implementation has a bug, we will never have a stable spec. Russ's original note said: Third, we could decide that the negotiation of key length was also a mistake. This approach would lead to three times as many IANA registry entries as the previous approach, but it might be a quick solution to the interoperability concerns. That's the part I disagree with. paul koning _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 17:23:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14460 for ; Fri, 29 Oct 2004 17:23:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdkT-0004cP-9m; Fri, 29 Oct 2004 16:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdDu-0004tQ-Di for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 16:19: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 QAA03366 for ; Fri, 29 Oct 2004 16:19:44 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdSF-00087p-BE for ipsec@ietf.org; Fri, 29 Oct 2004 16:34:36 -0400 Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TKJbDh075879 for ; Fri, 29 Oct 2004 13:19:39 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16770.39440.480000.71261@gargle.gargle.HOWL> References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> <16770.24109.878000.862040@gargle.gargle.HOWL> <16770.39440.480000.71261@gargle.gargle.HOWL> Date: Fri, 29 Oct 2004 13:19:20 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:29 PM -0400 10/29/04, Paul Koning wrote: >Sure, but the design all along has been that the algorithm ID selects >the algorithm, and parameters carry algorithm variables such as key >length. Except that it wasn't used for many years after the spec was implemented because there wasn't a commonly-used encryption algorithm that needed it until AES. I can't say exactly what people had problems with, but I can say that I had at least two implementers who said "we got it wrong the first time we tried" (and that they had fixed the problem before it got to the VPNC interop testing). > Paul> If it is so important that we add new ICV parameters, why > Paul> wasn't this discussed in any of the rounds of either protocols, > Paul> even in the WG and IETF last calls? > >If the issue is that it's too late to add the missing parameter, and >variable ICV length is needed, then I guess using multiple algorithm >IDs is a sensible workaround. In that case, I would find either >approach acceptable. Good to hear. It's never too late, of course, but if we go that route, it means yanking two RFCs out of the RFC Editor's queue, and postponing a third one that is hopefully ready to go into the queue. All of them would have to be revised to include the new parameter and a description of how to fill it in, and therefore they each would have to go through IETF last calls again and go through the IESG again. (I tried to type that without using my whiny voice, but I don't think I succeeded.) >It sounded like the issue with key length was that some >implementations didn't implement it right. Ok, so fix them, what's >the big deal? No big deal, and they did fix them. There are plenty of systems that do AES interoperably; see . > If we establish a precedent of changing the spec rather >than the implementation when an implementation has a bug, we will >never have a stable spec. Completely agree. It is complicated by the fact that RFC 2409 could not anticipate something like AES. The wording about key size is: When using an Encryption Algorithm that has a variable length key, this attribute specifies the key length in bits. (MUST use network byte order). This attribute MUST NOT be used when the specified Encryption Algorithm uses a fixed length key. It can be argued that AES-128 and AES-192 and AES-256 are different algorithms with fixed key sizes because they each use a different number of rounds of processing; it can be argued that they are the same algorithm that just has the number of rounds triggered by the key size. The person who decided to register AES for IKEv1 as a single algorithm that required the key size parameter may have felt better about the second interpretation. >Russ's original note said: > > Third, we could decide that the negotiation of key length was also a > mistake. This approach would lead to three times as many IANA > registry entries as the previous approach, but it might be a quick > solution to the interoperability concerns. > >That's the part I disagree with. Agree: going to #3 would be a bad idea because it could make things more difficult for current AES implementers. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 17:48:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17532 for ; Fri, 29 Oct 2004 17:48:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNeE0-0001Es-3e; Fri, 29 Oct 2004 17:23:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNe0k-0004BI-Hp for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 17:10:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12101 for ; Fri, 29 Oct 2004 17:10:11 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNeF4-00024O-Q9 for ipsec@ietf.org; Fri, 29 Oct 2004 17:25:04 -0400 Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TLA067086155; Fri, 29 Oct 2004 14:10:00 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Fri, 29 Oct 2004 14:10:01 -0700 To: Barbara Fraser , "Theodore Y. Ts'o" From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IPsec WG , Russ Housley Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis: Ready for IETF Last Call? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 again. It feels we're nearly done with draft-ietf-ipsec-rfc2401bis (which is still holding up IKEv2). There are a few open questions of interpretation from Mark Duffy, but they all seem like they could be dealt with in IETF Last Call instead of cycling the document again in the Working Group. Is this a good time, then, to move it out of the WG and to the IETF? Victory is within our grasp... --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 29 19:18:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25015 for ; Fri, 29 Oct 2004 19:18:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNfpv-0001As-TE; Fri, 29 Oct 2004 19:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNffd-00020l-Au for ipsec@megatron.ietf.org; Fri, 29 Oct 2004 18:56:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23378 for ; Fri, 29 Oct 2004 18:56:30 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNfu0-0004si-48 for ipsec@ietf.org; Fri, 29 Oct 2004 19:11:24 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i9TMu1jf011464; Fri, 29 Oct 2004 18:56:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.2.20041025184443.030a6b80@email> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> Date: Fri, 29 Oct 2004 18:55:11 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt 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: 156eddb66af16eef49a76ae923b15b92 Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Mark, Section 5, first para: I think we can change the text discussing SPD cache entries and SAs to avoid the unintended implication you noted. As you said, the cache model is adopted to simplify presentation and there was no intent to suggest that the mapping to a single SA is a side effect of the cache use and an efficiency issue. So, with the caveats we noted re multiple SAs for DSCP, etc., I think this issue is now closed. >>>In sect. 5.1 item 4: >>> >> >>Once a packet has crossed the IPsec boundary, it cannot be >>processed via IPsec again, unless it is bypassed, i.e., lopped. >>this is true in both directions, inbound or outbound. If one >>requires multiple passes through IPsec to protect a packet, then >>one must have entries in the SPD-O/I caches to allow such >>bypassing, as illustrated in Appendix E. > >The way I am looking at it, once a SG has applied tunnel mode IPsec >to a packet, it has created a *new* IP packet that is from the SG >itself. I view this new packet as originating *inside* the IPsec >boundary (comparable to the way that, say, IKE packets from the SG >originate from inside the IPsec boundary). The new, tunneled packet is inside the IPsec boundary, but it is past the point where we do outbound packet lookups. That was a major motivation re simplifying the processing model, i.e., avoiding looping inside of the IPsec boundary in support of nesting. This notion has been stable for quite a while, as we removed the requirement for support of SA bundles. the last list discussion of this took place back in early August when Mike Roe sent a message asking for clarification on how to set up entries in forwarding tables and in the SPD to effect the looping needed for nested SAs. >If on the other hand an SG is to view the tunnel mode packet that it >just created as having arrived from outside the IPsec boundary, that >seems to me to be quite confusing. What interface would it be >considered to have arrived from? Which (of potentially multiple) >SPDs should be used for the pseudo-inbound processing? How do I >(configuring the policy) distinguish these packets from ones that >really came in off the network? At the bottom line, why should an >SG treat an IPsec packet that it just created as though it just >arrived on an unprotected interface? I think the question of how one treats a packet as it emerges from IPsec processing is well illustrated in the set of figures we have added to 2401bis, going back to December of 2003. Figure 2 shows the output from AH/ESP processing going to the forwarding function, and shows a path from that function, through the SPD-I, and back to the SPD-selection function. This was described precisely to support the looping needed for nested SA processing. Still, let me answer the questions you raised. As per figure 2, this traffic goes from the forwarding module to the SPD-I. The inbound traffic discussion on page 52 says that a packet MAY be tagged with the interface IF that is necessary to support different SPD-Is. I guess we could say, in the outbound processing discussion, that if necessary, the traffic being looped back could be tagged as coming from this internal interface, if necessary, i.e., if there is more than one SPD-I. That would allow use of a different SPD-I for "real" external traffic vs. looped traffic, if needed. The example we gave in Appendix ?? did not make that assumption, i.e., it used just one SPD-I, which is the default. the bottom line is that we have said for about a year that this is how we would loop packets to effect nested SA processing. >>>In sect. 7.4 (BYPASS/DISCARD traffic) > > >Since we had the big discussion for PROTECT and decided that >stateful fragment checking is a MAY, I would expect the same >conclusion to apply for BYPASS. However, you seem to be taking the >position that unless this was specifically discussed for BYPASS, >that the standard in this area is defaulting to MUST. I don't see >why that should be the case. I am not sure that we defaulted a MUST for fragment reassembly for BYPASS, after deciding to make it a MAY for protected traffic. I thought that we changed it to MUST after some discussion on the list, after having listed it as MAY/SHOULD in the earlier draft, but I may be wrong. How about a quick straw poll, so we can make the word be MUST or MAY, depending on what folks decide. > > >>>In sect 8.2.1 (propagation of PMTU), it says that once it has >>>"learned" a new PMTU, the IPsec implementation should wait for >>>outbound traffic for the SA and "When such traffic arrives, if the >>>traffic would exceed the updated PMTU value the traffic MUST be >>>discarded and an appropriate ICMP PMTU message sent." >>> >>>I think that is the correct behavior *if* the packet had DF set, >>>but if it does not then the IPsec implementation should either >>>fragment then encrypt or encrypt then fragment, per its >>>configuration. >> >>Tbe processing described above is correct for IPv4 when the DF bit >>is set, as you noted. It also is appropriate for IPv6, because we >>can't fragment on the plaintext side for v6. maybe we could >>fragment on the ciphertext side, but that is still not in the >>spirit of v6, since we are an intermediate system performing >>fragmentation. The question is very poor performance that results >>for v4 or v6 if we fragment. How about compromise: for v6 we send >>the PMTU and drop the packet, as now described; for v4 we send the >>PMTU message, but still pass the packet, fragmenting on either side >>as configured. > >Let me break it into 3 cases: > >1. Original (cleartext) packet is IPv4 and has DF set: >I think you and I are agreed that it should discard the packet, and >send a PMTU ICMP message. right. >2. Original (cleartext) packet is IPv4 and has DF clear: >I think you are suggesting that the IPsec implementation send a PMTU >ICMP message but also fragment (before or after IPsec) and forward >the packet. I disagree with that. I agree it should fragment and >forward the packet, but I DO NOT agree that it should send the PMTU >ICMP. The reason is that the ICMP message that would be sent is >type 3 (Destination Unreachable) code 4 ("fragmentation needed and >DF set"). I do not think it is good practice to send "fragmentation >needed and DF set" in cases where DF was not set. whoops, good point. I guess we should just wait for hosts behind an SG to send traffic with DF set as part of PMTU discovery, and act accordingly. OK. > >3. Original (cleartext) packet is IPv6: >I think you and I are agreed that this should be treated just like case 1. right. >BTW I think the above cases cover all cases, regardless of whether a >tunnel mode IPsec encapsulation would be IPv4 or v6. agreed. >>>Appendix D has not been updated to align with what was eventually >>>decided, and so may lead to confusion. Perhaps it should just be >>>dropped? >> >> >>We were explicitly asked to preserve the analysis that motivated >>the final text in 2401bis, hence the appendix in question. The >>Appendix presents arguments for different approaches, and ends with >>the observation that we settled for one MUST and two MAYs. other >>than the question about fragment reassembly for BYPASS traffic, >>what parts of it do you feel are no longer consistent with the >>final text? > >Re-reading the appendix now, it doesn't strike me as badly as last >time :-) so I will largely withdraw this complaint. The only thing >I see from a quick look (maybe only a nit, I'll concede): > >"...essentially create a "non-initial fragment only" SA, precisely >the solution that the WG rejected." and >"The Working Group rejected the convention of creating an SA to >carry only non-initial fragments" >As reflected in sect 7.2, separate SAs may be used for non-initial fragments. > we'll revisit that chunk of text. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Oct 30 11:17:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28144 for ; Sat, 30 Oct 2004 11:17:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNuhO-0004LT-Pp; Sat, 30 Oct 2004 10:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNueL-0002dW-A1 for ipsec@megatron.ietf.org; Sat, 30 Oct 2004 10:56: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 KAA27232 for ; Sat, 30 Oct 2004 10:56:10 -0400 (EDT) Received: from web8407.mail.in.yahoo.com ([202.43.219.155]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNuse-0003No-Rt for ipsec@ietf.org; Sat, 30 Oct 2004 11:11:13 -0400 Received: (qmail 19529 invoked by uid 60001); 30 Oct 2004 14:55:29 -0000 Message-ID: <20041030145528.19527.qmail@web8407.mail.in.yahoo.com> Received: from [203.128.1.251] by web8407.mail.in.yahoo.com via HTTP; Sat, 30 Oct 2004 15:55:28 BST Date: Sat, 30 Oct 2004 15:55:28 +0100 (BST) From: khan wadood To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 8bit Subject: [Ipsec] AUTH payload - Issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit hi, I am very much confused regarding calculation of AUTH payload in message number no.3 As, it is written in the draft-ietf-ipsec-ikev2-17.txt 'In the case of a pre-shared key, the AUTH value is computed as: AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), )' Issues are: 1-How does the Responder verify the AUTH payload of the Initiator ?? 2-'Key Pad for IKEv2' i.e., 17 ASCII characters may be different on the Initiator and Responder side. So, the AUTH payload verification may fail on either side because of this ?? 3.What does 'msg octets' means for Initiator ?? and Responder ?? For inititator, does this mean ?? 'the first octet of the first SPI in the header of the message no.1 and end with the last octet of the last payload of the message no.1 where message no.1 is first message of init exchange. thanks in advance wadood ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Oct 31 03:18:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07201 for ; Sun, 31 Oct 2004 03:18:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COAhA-0002hg-Fo; Sun, 31 Oct 2004 03:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COAaN-0001SM-Qv for ipsec@megatron.ietf.org; Sun, 31 Oct 2004 02:57:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05684 for ; Sun, 31 Oct 2004 02:57:10 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COAp2-0003Fm-9K for ipsec@ietf.org; Sun, 31 Oct 2004 03:12:20 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9V7v5e21921; Sun, 31 Oct 2004 09:57:05 +0200 (EET) X-Scanned: Sun, 31 Oct 2004 09:56:54 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9V7usl8027415; Sun, 31 Oct 2004 09:56:54 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Pbam6P; Sun, 31 Oct 2004 09:56:53 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9V7uqa22884; Sun, 31 Oct 2004 09:56:52 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 31 Oct 2004 09:56:52 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 31 Oct 2004 09:56:51 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 31 Oct 2004 09:56:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] AUTH payload - Issues Date: Sun, 31 Oct 2004 09:56:51 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD8A@esebe056.ntc.nokia.com> Thread-Topic: [Ipsec] AUTH payload - Issues Thread-Index: AcS+lDDxx4C9Bjt9TwypANQUrJHvyQAijL9A To: , X-OriginalArrivalTime: 31 Oct 2004 07:56:51.0702 (UTC) FILETIME=[2E6D4160:01C4BF1F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable khan wadood writes: >=20 > hi, >=20 > I am very much confused regarding calculation of AUTH > payload in message number no.3=20 > As, it is written in the draft-ietf-ipsec-ikev2-17.txt >=20 > 'In the case of a pre-shared key, the AUTH value is > computed as: >=20 > AUTH =3D prf(prf(Shared Secret,"Key Pad for IKEv2"), > )' >=20 > Issues are:=20 >=20 > 1-How does the Responder verify the AUTH payload of > the Initiator ?? The responder performs the same calculation, and compares the value to the one sent by the initiator. > 2-'Key Pad for IKEv2' i.e., 17 ASCII characters may > be different on the Initiator and Responder side. So, > the AUTH payload verification may fail on either side > because of this ?? No, the string 'Key Pad for IKEv2' is the same on both sides=20 (i.e., it's not just any 17 ASCII characters, but the=20 characters 'K', 'e', 'y', ' ', etc.) > 3.What does 'msg octets' means for Initiator ?? and > Responder ?? See the first paragraph of Section 2.15. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Oct 31 10:37:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06925 for ; Sun, 31 Oct 2004 10:37:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COHbs-0000VP-Mq; Sun, 31 Oct 2004 10:27:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COHU8-0007gS-De for ipsec@megatron.ietf.org; Sun, 31 Oct 2004 10:19:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05507 for ; Sun, 31 Oct 2004 10:19:10 -0500 (EST) Received: from web8403.mail.in.yahoo.com ([202.43.219.151]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1COHid-0006hp-BL for ipsec@ietf.org; Sun, 31 Oct 2004 10:34:24 -0500 Received: (qmail 79096 invoked by uid 60001); 31 Oct 2004 15:18:19 -0000 Message-ID: <20041031151819.79094.qmail@web8403.mail.in.yahoo.com> Received: from [203.128.1.251] by web8403.mail.in.yahoo.com via HTTP; Sun, 31 Oct 2004 15:18:19 GMT Date: Sun, 31 Oct 2004 15:18:19 +0000 (GMT) From: khan wadood To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 8bit Subject: [Ipsec] Issues regarding Traffic Selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit hi, i have some issues regarding Traffic Selectors.. 1- Is there any need for Traffic Selectors in Transport mode ?? 2- There is no 1 to 1 mapping between Traffic Selector and SA in IKEv2, it seems to me that it is many to 1 mapping between Traffic Selectors and SA, is it so ?? 3- If so then how we get the selector value for an SA ?? For example, if we send two TS's in IKE_AUTH exchange. First TS agreed: address range: 10.2.16.0 - 10.2.16.255 port: 0 - 65535 Protocol ID: 0 second TS agreed: address range: 10.2.0.0 - 10.2.255.255 port: 0 - 65535 Protocol ID: 0 Both TS's maps to single SA (am i missing some action??). Now, how selector will select the respective SA from SAD ?? it might be confused ?? or we have to repeat the SA entry with respect to each selector. thanks in advance wadood ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Oct 31 16:24:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05004 for ; Sun, 31 Oct 2004 16:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CON88-0006UJ-2h; Sun, 31 Oct 2004 16:20:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CON45-0005zG-JU for ipsec@megatron.ietf.org; Sun, 31 Oct 2004 16:16:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04531 for ; Sun, 31 Oct 2004 16:16:39 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CONIq-0005UD-RO for ipsec@ietf.org; Sun, 31 Oct 2004 16:31:57 -0500 Received: from SriniSony (dhcp-50.intoto.com [10.1.5.50]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id i9VLJ6RQ003593; Sun, 31 Oct 2004 13:19:09 -0800 Message-Id: <200410312119.i9VLJ6RQ003593@intotoinc.com> From: "Srinivasa Rao Addepalli" To: "'khan wadood'" , Subject: RE: [Ipsec] Issues regarding Traffic Selectors Date: Sun, 31 Oct 2004 13:16:31 -0800 Organization: Intoto Inc MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041031151819.79094.qmail@web8403.mail.in.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcS/YAhJvHf65rjnS9uiWCPX1cIQjgALmrvA X-Spam-Score: 0.2 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 X-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="===============1669779633==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1669779633== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C4BF4B.D6B5AF20" This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C4BF4B.D6B5AF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of khan wadood Sent: Sunday, October 31, 2004 7:18 AM To: ipsec@ietf.org Subject: [Ipsec] Issues regarding Traffic Selectors hi, i have some issues regarding Traffic Selectors.. 1- Is there any need for Traffic Selectors in Transport mode ?? > Yes. Think of multi-homing scenarios. 2- There is no 1 to 1 mapping between Traffic Selector and SA in IKEv2, it seems to me that it is many to 1 mapping between Traffic Selectors and SA, is it so ?? > Yes, if you put it that way. 3- If so then how we get the selector value for an SA ?? For example, if we send two TS's in IKE_AUTH exchange. First TS agreed: address range: 10.2.16.0 - 10.2.16.255 port: 0 - 65535 Protocol ID: 0 second TS agreed: address range: 10.2.0.0 - 10.2.255.255 port: 0 - 65535 Protocol ID: 0 Both TS's maps to single SA (am i missing some action??). Now, how selector will select the respective SA from SAD ?? it might be confused ?? or we have to repeat the SA entry with respect to each selector. > Note that there is only one SPI, meaning that there is only one SA. It is local implementation matter on how this can be stored. thanks in advance wadood ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0064_01C4BF4B.D6B5AF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of khan wadood
Sent: Sunday, October 31, 2004 7:18 AM
To: ipsec@ietf.org
Subject: [Ipsec] Issues regarding Traffic Selectors

 

hi,

 

i have some issues regarding Traffic = Selectors..

 

1- Is there any need for Traffic Selectors = in

Transport mode ??

 

> Yes. Think of multi-homing = scenarios.

 

2- There is no 1 to 1 mapping between Traffic = Selector

and SA in IKEv2, it seems to me that it is many to = 1

mapping between Traffic Selectors and SA, is it so = ??

 

> Yes, if you put it that = way.

 

3- If so then how we get the selector value for an = SA

??

 

For example, if we send two TS's in IKE_AUTH = exchange.

 

First TS agreed:

address range: 10.2.16.0 - = 10.2.16.255

port: 0 - 65535

Protocol ID: 0

 

second TS agreed:

address range: 10.2.0.0 - = 10.2.255.255

port: 0 - 65535

Protocol ID: 0

 

Both TS's maps to single SA (am i missing = some

action??). Now, how selector will select = the

respective SA from SAD ?? it might be confused ?? = or

we have to repeat the SA entry with respect to = each

selector.

 

> Note that there is only one = SPI, meaning that there is only one SA. It is local implementation matter on = how this can be stored.

 

thanks in advance

 

wadood

 

_________________________________________________________________= _______

Yahoo! India Matrimony: Find your life partner = online

Go to: = http://yahoo.shaadi.com/india-matrimony

 

_______________________________________________=

Ipsec mailing list

Ipsec@ietf.org

https://www1.ietf.org/mailman/listinfo/ipsec

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