From ipsec-bounces@ietf.org Mon Mar 3 07:14:56 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7D03A6B33; Mon, 3 Mar 2008 07:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnI0ZKjM8SF4; Mon, 3 Mar 2008 07:14:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E628F3A68D2; Mon, 3 Mar 2008 07:14:50 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2FF3A67E4 for ; Mon, 3 Mar 2008 07:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZuBkApiT5Rd for ; Mon, 3 Mar 2008 07:14:44 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id 5E1503A68D2 for ; Mon, 3 Mar 2008 07:14:44 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k40so85966wah.25 for ; Mon, 03 Mar 2008 07:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=zkiogMhQpDIqt4MRNwIHCjQhaM7vEbrMCBu0nvoWVW8=; b=dF6ThnLM6pMnvl006D3oVBCIeUgqlfzYQdBBsZWxrUmwsUw2jyFhFVhPgs0akvRqDMQSrEdZyBBEperqk+drDeV9iOBHo1HG2EPaf3/lc0S7CEokNDkcy1VdhVz+ODU+lNdrVd/U2h46NjkHclvaRStGfHti493JfDpijX5uDZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=sqzg7QQXvs5qs6YTQnH2y1siHHNB8LLltXRmntu+XFJszRfTRmK8PoH7eWLSvQ935k2TZuzf40srmhOZcyXtphGs0gBCy+P1xmGewEbq08ojAnuhD70nHZDVmVD4Hb69RxkvbSb332N50K/P6UthE18JHCDzs3X8EU9vLxGuHYA= Received: by 10.114.81.1 with SMTP id e1mr116368wab.11.1204557273971; Mon, 03 Mar 2008 07:14:33 -0800 (PST) Received: by 10.114.110.7 with HTTP; Mon, 3 Mar 2008 07:14:33 -0800 (PST) Message-ID: Date: Mon, 3 Mar 2008 20:44:33 +0530 From: "Arnab Bakshi" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [IPsec] Regarding IPSec SA Attributes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi All, I was going through the IKE/ISAKMP specs(2408/2409). There is an area which I am not very clear about. => There has been no mention of the action to be taken when any Unknown SA attribute is received. Whether the IKE implementation should discard the transform payload or just the attribute it is not very clear. Can anybody help me out in actually how the above case is being handled? Thanks and Regards ------ Arnab _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 4 00:03:34 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01763A6E7F; Tue, 4 Mar 2008 00:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.824 X-Spam-Level: X-Spam-Status: No, score=-0.824 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6djAIcQxR63L; Tue, 4 Mar 2008 00:03:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519153A6EC4; Tue, 4 Mar 2008 00:03:30 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCA928C33C for ; Tue, 4 Mar 2008 00:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaK9T5rIpusl for ; Tue, 4 Mar 2008 00:03:23 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 0794328C595 for ; Tue, 4 Mar 2008 00:03:04 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0E8B41FA6215; Tue, 4 Mar 2008 00:02:55 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 4 Mar 2008 00:02:55 -0800 (PST) Message-ID: <1283.69.12.173.8.1204617775.squirrel@www.trepanning.net> In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD9192382D@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD9192382D@CORPUSMX20A.corp.emc.com> Date: Tue, 4 Mar 2008 00:02:55 -0800 (PST) From: "Dan Harkins" To: Black_David@emc.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi David, What value is there in enabling CCM? Like GCM, it is fragile in the sense that if an IV is ever reused all security is lost. But unlike GCM it cannot support high-speed data rates because of it's two-pass nature. If you're going to enable a two-pass AEAD scheme why not consider SIV which is resistant to IV misuse? That way if you need robustness and can sacrifice speed you use SIV, if you are assured that the cipher mode cannot be misused and want to take advantage of the speed gain you use GCM. It doesn't make sense to add a cipher which is both slower and fragile. regards, Dan. On Fri, February 29, 2008 11:55 am, Black_David@emc.com wrote: > David McGrew and I would appreciate comments on this > draft. Its primary purpose is to enable use of AES GCM > and AES CCM for the IKEv2 encrypted payload - currently, > these algorithms can be used with ESP, but not with > IKEv2 proper (i.e., IKEv2 can negotiate ESP usage of > GCM and CCM, but the IKEv2 encrypted payload can't > currently be encrypted with GCM or CCM). > > This draft does so by applying the Authenticated > Encryption framework from RFC 5116 to IKEv2's encrypted > payload, as AES GCM, AES CCM and other combined modes > are examples of authenticated encryption algorithms. > The draft also supplies the remaining details needed > for use of AES GCM and AES CCM with IKEv2. This > approach should make things easier for future > authenticated encryption algorithms because the > IKEv2-generic aspects (e.g., data that receives > integrity coverage but is not encrypted) won't have > to be respecified. > > While this draft has already received some good review > (and we thank the reviewers), like any -00 version, it's > not complete. The only major technical content that's > missing is completing the connection to RFC 5116, mostly > explaining how this draft relates to the specific AEAD > algorithms defined in RFC 5116. As part of doing this, > additional AEAD algorithm identifiers for AES CCM will be > defined to the version of AES CCM specified in RFC 4309, > as the AEAD CCM algorithms in RFC 5116 differ from > those in RFC 4309. > > There are a few technical issues that we are looking > for input on: > > 1) Key size. IPsec in general allows 192 bit AES > keys, but RFC 5116 currently does not. Is it > ok to not allow 192 bit AES keys when AES GCM > and AES CCM are used for the IKEv2 encrypted > payload. > 2) ICV size. Both RFC 4106 (GCM) and 4309 (CCM) are > fairly permissive about 8-octet and 12-octet > ICVs. David McGrew would like to generally > prohibit ICV sizes other than 16-octets and hence > only specify and allow support of 16-octet ICVs > in this draft. That would place tighter > restrictions on AES GCM and AES CCM usage with > IKEv2 than with ESP unless something else is done. > 3) Padding. Both AES GCM and AES CCM only require > padding only to a 32-bit alignment (this is > done here for commonality with ESP). Is that > a general characteristic of authenticated > encryption algorithms, or are there algorithms > that may need more padding (e.g., to the AES > encryption block size)? > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >> On Behalf Of Internet-Drafts@ietf.org >> Sent: Wednesday, February 20, 2008 1:10 PM >> To: IPsec WG >> Subject: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Using Authenticated Encryption Algorithms >> with the Encrypted Payload of the Internet Key Exchange version 2 >> (IKEv2) Protocol >> Author(s) : D. Black, D. McGrew >> Filename : draft-black-ipsec-ikev2-aead-modes-00.txt >> Pages : 14 >> Date : 2008-2-15 >> >> An authenticated encryption algorithm combines encryption and >> integrity into a single operation; such algorithms may also be >> referred to as combined modes of an encryption cipher or >> as combined >> mode algorithms. This document describes the use of authenticated >> encryption algorithms with the Encrypted Payload of the >> Internet Key >> Exchange version 2 (IKEv2) protocol. >> >> The use of two specific authenticated encryption >> algorithms with the >> IKEv2 Encrypted Payload is also described; these two >> algorithms are >> the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES >> GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional >> documents may describe use of other authenticated encryption >> algorithms with the IKEv2 Encrypted Payload. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-black-ipsec-ikev2-ae > ad-modes-00.txt >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> http://www.ietf.org/mailman/listinfo/ipsec >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 4 09:21:48 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5F128C77D; Tue, 4 Mar 2008 09:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16WmDt7Ucsp8; Tue, 4 Mar 2008 09:21:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1CC28C361; Tue, 4 Mar 2008 09:21:24 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DDF28C313 for ; Tue, 4 Mar 2008 09:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHlOQzLlQCvP for ; Tue, 4 Mar 2008 09:21:17 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id D6E5C3A6CB0 for ; Tue, 4 Mar 2008 09:18:08 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so771639fgg.41 for ; Tue, 04 Mar 2008 09:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=e1Olsn8fwCi5B0XVUfKJpD06pBuP76VwPfo+ElsJUcg=; b=IzN6CBcxswM7wabs6Yb3AP48HGPVXQSn8ZhygqvmEsbmOsZpaG/bOVwCMK2GMfdQbKucJ3fCHCITqsiekxpQABw1Du3OgLP+ZMjAqrWIl5p5FYF6RW++2rgSNUfDKbSOdG306rjcX5O1wAXbz5cT56QMD6uIAQw+s+dNJlGehTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Iay+n7Tlsj2pSkiwHAwFf1NRRjskKXPGSv8eOShAxBNIxuU0LR+UGNb3E3ETR/TDnNjwkV0RUrvliPtpg4rvaizfguGVM3GbYC99+Io7wjdED7jj00vb/QEckfhsEMJXYHDyN7sgBAOVVinWTe6wwX6ssXWXWWguG0BZDL0/G58= Received: by 10.86.31.18 with SMTP id e18mr1557116fge.38.1204651078522; Tue, 04 Mar 2008 09:17:58 -0800 (PST) Received: by 10.86.35.18 with HTTP; Tue, 4 Mar 2008 09:17:58 -0800 (PST) Message-ID: <729b68be0803040917wa1da4d6ia676d56409499885@mail.gmail.com> Date: Tue, 4 Mar 2008 18:17:58 +0100 From: "Jean-Michel Combes" To: "Paul Hoffman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: IPsec WG Subject: Re: [IPsec] Fwd: I-D Action:draft-hoffman-ikev2bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I have two questions regarding this draft. o Protocol ID field (section 3.10 - Protocol ID description) Is it normal the sentence "For IKE_SA notifications, this field MUST be one (1)" has been removed (in fact, this sentence has been removed since the version -01 of the draft)? o SPI field (section 3.10 - SPI Size description) It is said that "For a notification concerning the IKE_SA, the SPI Size MUST be zero.". Does it mean that the SPI MUST be empty too? Or is it just a way to identify this is a notification concerning the IKE_SA (and so the SPI field may be not empty) because, in this case, there is no more assigned value for the Protocol ID field? Thanks in advance. Best regards. JMC. 2008/2/25, Paul Hoffman : > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > Title : Internet Key Exchange Protocol: IKEv2 > > Author(s) : C. Kaufman, et al. > > Filename : draft-hoffman-ikev2bis-03.txt > > Pages : 129 > > Date : 2008-02-25 > > > >This document describes version 2 of the Internet Key Exchange (IKE) > >protocol. It is a restatement of RFC 4306, and includes all of the > >clarifications from RFC 4718. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-hoffman-ikev2bis-03.txt > > This version has a bunch of changes, some significant. Please read > the change log at the end of the document for a list. > > We are always seeking comments, particularly from new IKEv2 > developers (old developers are of course welcome to say what they > just discovered...). > > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > http://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 5 09:59:00 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4054928C37A; Wed, 5 Mar 2008 09:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGi1rKjAooKp; Wed, 5 Mar 2008 09:58:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6F028C7E9; Wed, 5 Mar 2008 09:58:39 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCD228C7FD for ; Wed, 5 Mar 2008 09:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhdmDGAYCMaE for ; Wed, 5 Mar 2008 09:58:36 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 60AAC3A6803 for ; Wed, 5 Mar 2008 09:57:55 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m25HvhnP004930; Wed, 5 Mar 2008 12:57:43 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Wed, 5 Mar 2008 12:57:43 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m25HvalN004153; Wed, 5 Mar 2008 12:57:41 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 12:57:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 12:56:52 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD9192386B@CORPUSMX20A.corp.emc.com> In-Reply-To: <1283.69.12.173.8.1204617775.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt Thread-Index: Ach9zjWfLmsBw/QpQiKaQDRAB5atHQBGvmmA References: <8CC6CEAB44F131478D3A7B429ECACD9192382D@CORPUSMX20A.corp.emc.com> <1283.69.12.173.8.1204617775.squirrel@www.trepanning.net> To: X-OriginalArrivalTime: 05 Mar 2008 17:57:30.0585 (UTC) FILETIME=[61A72490:01C87EEA] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: M and A Terms X-Tablus-Action: allow Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan, > What value is there in enabling CCM? Like GCM, it is fragile > in the sense that if an IV is ever reused all security is lost. > But unlike GCM it cannot support high-speed data rates because > of it's two-pass nature. The short answer is consistency. GCM and CCM are specified for ESP, so this draft specifies them for the IKEv2 Encrypted Payload. Unless we want to move RFC 4309 to Historic status, this seems like a reasonable thing to do. I believe that there's much more implementation interest in GCM than CCM. > If you're going to enable a two-pass > AEAD scheme why not consider SIV which is resistant to IV > misuse? That way if you need robustness and can sacrifice > speed you use SIV, if you are assured that the cipher mode > cannot be misused and want to take advantage of the speed > gain you use GCM. I have no objection in principle to specifying SIV for IKEv2. Where is SIV specified for ESP? > It doesn't make sense to add a cipher which is both slower > and fragile. IMHO, this should be done consistently for ESP and IKEv2. If you believe that CCM should no longer be used, I suggest writing an Internet-Draft that explains why as a justification for moving RFC 4309 (CCM for ESP) to Historic status. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 5 10:16:07 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489A928C820; Wed, 5 Mar 2008 10:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RJLqXq8p1ZU; Wed, 5 Mar 2008 10:16:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62ACB3A6C92; Wed, 5 Mar 2008 10:16:03 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9537D3A6978 for ; Wed, 5 Mar 2008 10:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFkVs890uSVG for ; Wed, 5 Mar 2008 10:15:57 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D9EBE28C336 for ; Wed, 5 Mar 2008 10:15:57 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JWy9b-0001CE-3r; Wed, 05 Mar 2008 13:15:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD9192386B@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD9192382D@CORPUSMX20A.corp.emc.com> <1283.69.12.173.8.1204617775.squirrel@www.trepanning.net> <8CC6CEAB44F131478D3A7B429ECACD9192386B@CORPUSMX20A.corp.emc.com> Date: Wed, 5 Mar 2008 13:15:48 -0500 To: Black_David@emc.com From: Stephen Kent Cc: ipsec@ietf.org, dharkins@lounge.org Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org David, One observation about crypto modes for IPsec and IKE: - IKE has very low bandwidth requirements, so the motivation to adopt crypto modes that offer higher performance is pretty low here. The notion of having the same mode for both ESP and IKE has some attraction, but is it that critical? Crypto chip vendors support protocols other than IPsec and IKE with the same chips. if we use a mode for IKE that is also used by other protocols, then that mode will likely be there anyway. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 5 14:26:29 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979C128C73F; Wed, 5 Mar 2008 14:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.615 X-Spam-Level: X-Spam-Status: No, score=-100.615 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlHxm0u5pBzU; Wed, 5 Mar 2008 14:26:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C1D3A6884; Wed, 5 Mar 2008 14:26:28 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0691F3A6C3A for ; Wed, 5 Mar 2008 01:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuFqi6mSOf4Y for ; Wed, 5 Mar 2008 01:53:24 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id CCB683A6E3B for ; Wed, 5 Mar 2008 01:52:30 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id u2so4430397uge.46 for ; Wed, 05 Mar 2008 01:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-disposition:content-type:content-transfer-encoding:message-id:sender; bh=1bzwH+2tBg/56XWqUgnUZQXuho4X2Y9eYjDV8bwdJGM=; b=x6+9J2T3wb2++OwZ/E/iVx+PHlzoCuwqxfih2IW7L6InjvPDkhf19LQVt2ebKVbrdbj+pB5h2+i01YPnjjVaueGL92x/iTZ50DMOV+1+3yM242FgYvQm+mUyHNsD7JJ3UengrMIGYPNaeLn6lttH8h+X7Hv6IeTD5htft+j2QFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-disposition:content-type:content-transfer-encoding:message-id:sender; b=IKfv7VbLNntv1TYR7Y37JIDDmiYbm+XWT4bFBN9AGxpgsXPhABPNWTaGdc1ZaB18/0GfwKiwwmYoRxqoY3MndlS+kx8q8ryxFrVxHvW1DuNrLcz5DqE0M9Rsy61g+aGTj38/xxftRjme9SxhwfYT1+Syx6QhJIMG62HloRjfD1Q= Received: by 10.78.168.6 with SMTP id q6mr5659317hue.65.1204710739933; Wed, 05 Mar 2008 01:52:19 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 6sm4801318nfv.19.2008.03.05.01.52.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Mar 2008 01:52:18 -0800 (PST) From: Julien Laganier To: ipv6@ietf.org Date: Wed, 5 Mar 2008 10:53:22 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200803051053.24482.julien.IETF@laposte.net> X-Mailman-Approved-At: Wed, 05 Mar 2008 14:26:27 -0800 Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] Update for ikev2-ipv6-config draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wednesday 13 February 2008, Pasi.Eronen@nokia.com wrote: > Hi, > > I have posted a new version of the ikev2-ipv6-config draft > (http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-ipv6-config) > which incorporates some new ideas based on good discussions > in Vancouver (Hemant and Dave, thanks!). > > In particular, Section 5 has new text discussing the most important > design choices to be made, and Appendix A has additional solution > sketches for several design choice combinations. > > Section 6 still proposes the same solution as in draft version -01; > that is, point-to-point link model where prefixes are assigned in > IKEv2 configuration payloads, and access control is enforced by > IPsec (traffic selectors in SAD/SPD). To me this seems to be the > simplest solution -- however, the additional sketches in Appendix A > should make it easier to compare different alternatives; and > comments about them would be especially welcome! Hello Pasi, Thanks for updating your draft. I think this is useful work. I have some comments below: 3.2. Link-Local Addresses The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 addresses of all types are assigned to interfaces, not nodes. [..] All interfaces are required to have at least one Link-Local unicast address". Currently, the virtual interface created by IKEv2 configuration payloads does not have link-local addresses. This violates [IPv6Addr] and prevents the use of protocols that require link-local addresses, such as [MLDv2]. Here you could mention DHCPv6 as well (and you are in Section 3.5, with DHCPv6 PD). If one has a link-local address, it can use DHCPv6 to retrieve various configuration parameters from the DHCPv6 server, besides IPv6 address and DNS server address which are already handled via the CFG_* exchange. That would allow to decouple introduction of new configuration parameters from IKEv2 since only DHCPv6 support would be needed. 3.4. Interface Identifier Selection In the message exchange shown in Figure 2, the gateway chooses the interface ID used by the client. It is also possible for the client to request a specific interface ID; the gateway then chooses the prefix part. This approach complicates the use of Cryptographically Generates Addresses [CGA]. With CGAs, the interface ID cannot be calculated before the prefix is known. The client could first obtain a non-CGA address to determine the prefix, and then send a separate CFG_REQUEST to obtain a CGA address with the same prefix. However, this approach requires that the IKEv2 software component provides an interface the component managing CGAs; an ugly implementation dependency that would be best avoided. nit: s/an interface the/an interface to the/ 4.1. Main Requirements [...] o A VPN client can be assigned multiple prefixes for use on the client-gateway link. The client does not have to know beforehand how many prefixes are needed. [...] o It should be possible to share the VPN access over a local area network connection, without requiring anything special from other hosts in the local network (beyond minimal IPv6 node requirements specified in [RFC4294]). These two requirements turn into the ability for client to be delegated prefixes while not assigning them to the client-gateway link. They could then be included in the negotiated TS's and routed appropriately by the gateway to the client. The ability to do prefix delegation with DHCP within the IPsec tunnel interface could be useful for NEMO prefix delegation. Right now it is not possible to use DHCP PD out of the box for NEMO prefix delegation since multicast DHCP messages cannot be sent through an IPsec tunnel between the NEMO Mobile Router and the Home Agent. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 5 15:16:17 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CF128C2F0; Wed, 5 Mar 2008 15:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.504 X-Spam-Level: X-Spam-Status: No, score=-101.504 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jeRkBUsSmvI; Wed, 5 Mar 2008 15:16:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6CA3A689F; Wed, 5 Mar 2008 15:16:15 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097193A689F for ; Wed, 5 Mar 2008 15:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvOfD4aF83Tu for ; Wed, 5 Mar 2008 15:16:13 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 9881D3A6815 for ; Wed, 5 Mar 2008 15:16:13 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m25NFpL3001762; Wed, 5 Mar 2008 18:15:51 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Wed, 5 Mar 2008 18:15:50 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m25NFT35022376; Wed, 5 Mar 2008 18:15:48 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 18:15:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 18:15:16 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD9192386E@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt Thread-Index: Ach+7PqN3CcFICX+RYy2ltuGQEfDfQAJKgLg References: <8CC6CEAB44F131478D3A7B429ECACD9192382D@CORPUSMX20A.corp.emc.com><1283.69.12.173.8.1204617775.squirrel@www.trepanning.net><8CC6CEAB44F131478D3A7B429ECACD9192386B@CORPUSMX20A.corp.emc.com> To: X-OriginalArrivalTime: 05 Mar 2008 23:15:18.0014 (UTC) FILETIME=[C6B9E9E0:01C87F16] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_NAME_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: M and A Terms X-Tablus-Action: allow Cc: ipsec@ietf.org, Black_David@emc.com Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Steve, > One observation about crypto modes for IPsec and IKE: > > - IKE has very low bandwidth requirements, so the motivation > to adopt crypto modes that offer higher performance is pretty low > here. The notion of having the same mode for both ESP and IKE has > some attraction, but is it that critical? Crypto chip vendors > support protocols other than IPsec and IKE with the same chips. if > we use a mode for IKE that is also used by other protocols, then that > mode will likely be there anyway. I appreciate the observation and believe it's correct, but I also believe that there are additional considerations. This draft has been motivated in part by the adaptation of IKEv2 and ESP to SCSI, and clear interest has been expressed by the SCSI standards organization (T10) in using authenticated encryption with the SCSI version of IKEv2, mostly on the grounds of being able to use the same encryption mode for both IKEv2 and ESP. A major contributing factor is that for simplicity, the concept of CHILD SAs and the associated IKEv2 negotiation pass that enables use of different algorithms for the IKE SA and CHILD SA were both removed as part of the SCSI work. Some of these SCSI implementations of IKE and ESP may be in software, as the use cases do not involve encryption of all transmitted data (e.g., an important initial motivating use case has been inband keying of a tape drive that has onboard encryption), hence the functional footprint may matter. In addition, GCM in particular has such compelling hardware implementation advantages over a separate integrity computation that I'm not sure that all crypto hardware is always going to support something like CBC plus an integrity hash when one considers what's involved in fast hardware support for the SHA2 hashes. Also, one argument for authenticated encryption is that it is authenticated (ok, that's obvious), hence its use removes any possibility of an "encryption without data integrity authentication" security weakness, and for that that reason, I think we should be enabling and encouraging its use. I don't know that any of these are "critical" reasons, but I also don't think "critical" is the right decision level. This is a clear functional gap in IKEv2, and closing it not only supports use of a variant of IKEv2 in another standards body, but also adds flexibility to implementations and encourages use of technology that eliminates a potential security weakness. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 5 15:27:48 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29EF73A6815; Wed, 5 Mar 2008 15:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.49 X-Spam-Level: X-Spam-Status: No, score=-100.49 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HAwHiIWxddL; Wed, 5 Mar 2008 15:27:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3541628C2C6; Wed, 5 Mar 2008 15:27:46 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839203A688A for ; Wed, 5 Mar 2008 15:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx5M-2H0NT+X for ; Wed, 5 Mar 2008 15:27:43 -0800 (PST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id BFDA43A6815 for ; Wed, 5 Mar 2008 15:27:43 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.24.43.174]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JX31J-0005KU-3c; Wed, 05 Mar 2008 18:27:33 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD9192386E@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD91923 82D@CORPUSMX20A.corp.emc.com><1283.69.12.173.8.1204617775.squirrel@www.tre panning.net><8CC6CEAB44F131478D3A7B429ECACD9192386B@CORPUSMX20A.corp.emc.c om> <8CC6CEAB44F131478D3A7B429ECACD9192386E@CORPUSMX20A.corp.emc.com> Date: Wed, 5 Mar 2008 18:26:26 -0500 To: Black_David@emc.com From: Stephen Kent Cc: ipsec@ietf.org, Black_David@emc.com Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org David, Thanks for articulating some additional motivations for defining use of GCM in IKEv2. I think that adding this as an optional, additional crypto capability is OK. Makig it the default or mandatory to implement for IPsec in general would be a harder argument. However, you noted that the SCSI context is a major focus, and their profile is not the general case, so ... Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 5 16:06:21 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DDE3A685A; Wed, 5 Mar 2008 16:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.403 X-Spam-Level: X-Spam-Status: No, score=-101.403 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbrGARmxMHtS; Wed, 5 Mar 2008 16:06:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6433A6915; Wed, 5 Mar 2008 16:06:20 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757163A685A for ; Wed, 5 Mar 2008 16:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+p5BaEAMmUi for ; Wed, 5 Mar 2008 16:06:18 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 918D03A6915 for ; Wed, 5 Mar 2008 16:06:18 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m2605r6G016159; Wed, 5 Mar 2008 19:05:53 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Wed, 5 Mar 2008 19:05:53 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m26058gR017623; Wed, 5 Mar 2008 19:05:51 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 19:04:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 19:04:57 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91923870@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt Thread-Index: Ach/GIM6FeM9WpcFS9mfvN+btTqYOAAA74hQ References: <8CC6CEAB44F131478D3A7B429ECACD91923 82D@CORPUSMX20A.corp.emc.com><1283.69.12.173.8.1204617775.squirrel@www.tre panning.net><8CC6CEAB44F131478D3A7B429ECACD9192386B@CORPUSMX20A.corp.emc.c om> <8CC6CEAB44F131478D3A7B429ECACD9192386E@CORPUSMX20A.corp.emc.com> To: X-OriginalArrivalTime: 06 Mar 2008 00:04:58.0149 (UTC) FILETIME=[B7066D50:01C87F1D] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: M and A Terms X-Tablus-Action: allow Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Steve, > Thanks for articulating some additional motivations for defining use > of GCM in IKEv2. > > I think that adding this as an optional, additional crypto capability > is OK. Making it the default or mandatory to implement for IPsec in > general would be a harder argument. However, you noted that the SCSI > context is a major focus, and their profile is not the general case, > so ... I agree, and I'm deliberately not making the "harder argument" - the goal of this draft is only to make authenticated encryption algorithms such as GCM available as an "optional, additional crypto capability" for IKEv2. I have no intention of making authenticated encryption (e.g., GCM) "the default or mandatory to implement" for IKEv2. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 6 03:36:46 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7273A6D96; Thu, 6 Mar 2008 03:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpn8zFwth0Ez; Thu, 6 Mar 2008 03:36:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9259A28C263; Thu, 6 Mar 2008 03:36:25 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9B628C7F0 for ; Thu, 6 Mar 2008 03:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+L01jG6+XFj for ; Thu, 6 Mar 2008 03:36:23 -0800 (PST) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 72E5528C10E for ; Thu, 6 Mar 2008 03:36:23 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id m26BZjag010201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 13:35:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m26BZh4o026759; Thu, 6 Mar 2008 13:35:43 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18383.55055.704062.929767@fireball.kivinen.iki.fi> Date: Thu, 6 Mar 2008 13:35:43 +0200 From: Tero Kivinen To: Black_David@emc.com In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91923870@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD91923 82D@CORPUSMX20A.corp.emc.com> <1283.69.12.173.8.1204617775.squirrel@www.tre panning.net> <8CC6CEAB44F131478D3A7B429ECACD9192386B@CORPUSMX20A.corp.emc.c om> <8CC6CEAB44F131478D3A7B429ECACD9192386E@CORPUSMX20A.corp.emc.com> <8CC6CEAB44F131478D3A7B429ECACD91923870@CORPUSMX20A.corp.emc.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 73 min Cc: ipsec@ietf.org, kent@bbn.com Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Black_David@emc.com writes: > Steve, > > > Thanks for articulating some additional motivations for defining use > > of GCM in IKEv2. > > > > I think that adding this as an optional, additional crypto capability > > is OK. Making it the default or mandatory to implement for IPsec in > > general would be a harder argument. However, you noted that the SCSI > > context is a major focus, and their profile is not the general case, > > so ... > > I agree, and I'm deliberately not making the "harder argument" - the > goal of this draft is only to make authenticated encryption algorithms > such as GCM available as an "optional, additional crypto capability" > for IKEv2. I have no intention of making authenticated encryption > (e.g., GCM) "the default or mandatory to implement" for IKEv2. For me the most important issue is that IKEv2 shares same encryption algoritm numbers for both ESP and IKEv2 payloads, and there has not been description how to use those combined modes with IKEv2. Some people have argued that it is "obvious" how they are used and claimed they can be used. I do not think it is obvious, thus I think we either need document saying they are not to be used, or we define how to use them. I think defining how they are used is better option from those two. Some comments about the draft: > 1. Introduction > ... > with IKEv1, thus limiting initial specifications of AES combined mode > usage for IPsec to the Encapsulating Security Payload (ESP) > [RFC2406]. The current version of ESP is version 2, ESPv2 [RFC4303]. There is no versions on the ESP, and I think the current RFC4303 was mostly referenced as ESPv3, not version 2. I think it would be better to change that to just say: The curren version of ESP is specified in RFC4303. or something like that. > 3. IKEv2 Encrypted Payload Data > ... > The length of the Padding field MUST be chosen so that the number of > octets in the Encrypted Payload is a multiple of four, in order to > satisfy IKEv2 data alignment needs. IKEv2 does not have any data alignment needs, and the data fields in the IKEv2 might have any alignment. For example certficiate payloads etc can have any length and payloads after that will be unaligned. We might want to still limit the alignment to 4 bytes even when IKEV2 do not require so, but we should not claim it is because of IKEv2 data alignment needs. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 6 14:08:28 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECDC28CB37; Thu, 6 Mar 2008 14:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.394 X-Spam-Level: X-Spam-Status: No, score=-101.394 tagged_above=-999 required=5 tests=[AWL=-0.957, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbzY2faCjGzF; Thu, 6 Mar 2008 14:08:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C178028CA86; Thu, 6 Mar 2008 14:03:39 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10FF28CA86 for ; Thu, 6 Mar 2008 14:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeskecVV598T for ; Thu, 6 Mar 2008 14:03:33 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 594A628CA14 for ; Thu, 6 Mar 2008 14:00:59 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m26M0lwv002523; Thu, 6 Mar 2008 17:00:47 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Thu, 6 Mar 2008 17:00:47 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m26M0BEL002106; Thu, 6 Mar 2008 17:00:43 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 17:00:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 17:00:16 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD9192387D@CORPUSMX20A.corp.emc.com> In-Reply-To: <18383.55055.704062.929767@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt Thread-Index: Ach/fk+W2Cui/uRWRUuwcYjm4zkEWgAU6LKQ References: <8CC6CEAB44F131478D3A7B429ECACD9192382D@CORPUSMX20A.corp.emc.com><1283.69.12.173.8.1204617775.squirrel@www.trepanning.net><8CC6CEAB44F131478D3A7B429ECACD9192386B@CORPUSMX20A.corp.emc.com><8CC6CEAB44F131478D3A7B429ECACD9192386E@CORPUSMX20A.corp.emc.com><8CC6CEAB44F131478D3A7B429ECACD91923870@CORPUSMX20A.corp.emc.com> <18383.55055.704062.929767@fireball.kivinen.iki.fi> To: X-OriginalArrivalTime: 06 Mar 2008 22:00:18.0600 (UTC) FILETIME=[77479280:01C87FD5] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: M and A Terms X-Tablus-Action: allow Cc: ipsec@ietf.org, Black_David@emc.com Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero, Thanks for looking at the draft. The ESP change sounds fine. Regarding alignment: > IKEv2 does not have any data alignment needs, and the data fields in > the IKEv2 might have any alignment. For example certificate payloads > etc can have any length and payloads after that will be unaligned. > > We might want to still limit the alignment to 4 bytes even when > IKEV2 do not require so, but we should not claim it is because > of IKEv2 data alignment needs. The heritage of that text is that it was copied from text specifying use of the algorithms with ESP. On this basis, I think we can just drop this alignment text for IKEv2, as neither GCM nor CCM has any inherent alignment requirements. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Thursday, March 06, 2008 6:36 AM > To: Black, David > Cc: kent@bbn.com; ipsec@ietf.org > Subject: Re: [IPsec] I-D > ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt > > Black_David@emc.com writes: > > Steve, > > > > > Thanks for articulating some additional motivations for > defining use > > > of GCM in IKEv2. > > > > > > I think that adding this as an optional, additional > crypto capability > > > is OK. Making it the default or mandatory to implement > for IPsec in > > > general would be a harder argument. However, you noted > that the SCSI > > > context is a major focus, and their profile is not the > general case, > > > so ... > > > > I agree, and I'm deliberately not making the "harder argument" - the > > goal of this draft is only to make authenticated encryption > algorithms > > such as GCM available as an "optional, additional crypto capability" > > for IKEv2. I have no intention of making authenticated encryption > > (e.g., GCM) "the default or mandatory to implement" for IKEv2. > > For me the most important issue is that IKEv2 shares same encryption > algoritm numbers for both ESP and IKEv2 payloads, and there has not > been description how to use those combined modes with IKEv2. Some > people have argued that it is "obvious" how they are used and claimed > they can be used. I do not think it is obvious, thus I think we either > need document saying they are not to be used, or we define how to use > them. I think defining how they are used is better option from those > two. > > Some comments about the draft: > > > 1. Introduction > > ... > > with IKEv1, thus limiting initial specifications of AES > combined mode > > usage for IPsec to the Encapsulating Security Payload (ESP) > > [RFC2406]. The current version of ESP is version 2, > ESPv2 [RFC4303]. > > There is no versions on the ESP, and I think the current RFC4303 was > mostly referenced as ESPv3, not version 2. I think it would be better > to change that to just say: > > The curren version of ESP is specified in RFC4303. > > or something like that. > > > 3. IKEv2 Encrypted Payload Data > > ... > > The length of the Padding field MUST be chosen so that > the number of > > octets in the Encrypted Payload is a multiple of four, in > order to > > satisfy IKEv2 data alignment needs. > > > IKEv2 does not have any data alignment needs, and the data fields in > the IKEv2 might have any alignment. For example certficiate payloads > etc can have any length and payloads after that will be unaligned. > > We might want to still limit the alignment to 4 bytes even when IKEV2 > do not require so, but we should not claim it is because of IKEv2 data > alignment needs. > -- > kivinen@safenet-inc.com > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 6 14:17:39 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A5328C263; Thu, 6 Mar 2008 14:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.611 X-Spam-Level: X-Spam-Status: No, score=-100.611 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7cbuo3hu-Bt; Thu, 6 Mar 2008 14:17:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B70328C260; Thu, 6 Mar 2008 14:17:38 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2A028C260 for ; Thu, 6 Mar 2008 14:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLHxiAhBzWtX for ; Thu, 6 Mar 2008 14:17:36 -0800 (PST) Received: from ins1.sd.spawar.navy.mil (ins1.sd.spawar.navy.mil [IPv6:2001:480:10:4::2]) by core3.amsl.com (Postfix) with ESMTP id CF5BD28C25D for ; Thu, 6 Mar 2008 14:17:35 -0800 (PST) Received: from [128.49.163.29] (2872sun.spawar.navy.mil [128.49.163.29]) by ins1.sd.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id m26MHLqG016431; Thu, 6 Mar 2008 14:17:24 -0800 Message-ID: <47D06D71.8080705@spawar.navy.mil> Date: Thu, 06 Mar 2008 14:17:21 -0800 From: Jeffrey Sun User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Cc: IPsec WG Subject: [IPsec] Bug: Section 2.15 - Responder Signed Octets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Current: The responder's signed octets can be described as: ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfIDPayload RestOfRespIDPayload = IDType | RESERVED | InitIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload) Suggested: The responder's signed octets can be described as: ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfIDPayload RestOfRespIDPayload = IDType | RESERVED | RespIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload) Comment: Changed "InitIDData" to "RespIDData". Unless I'm mistaken that "Init" stands for "Initiator", it should be "RespIDData". It's really a minor issue since RestofRespIDPayload infers the IDr Payload (and the Responder's Identification Data). - Jeff Sun _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 12 07:34:10 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAD628C709; Wed, 12 Mar 2008 07:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B9jnLwNMz0Q; Wed, 12 Mar 2008 07:34:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D33C3A6E80; Wed, 12 Mar 2008 07:34:09 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F8A28C1B5 for ; Wed, 12 Mar 2008 07:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE6Ww5G-hsLe for ; Wed, 12 Mar 2008 07:34:03 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id 5DDD73A6E80 for ; Wed, 12 Mar 2008 07:34:03 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 578DB10028008 for ; Wed, 12 Mar 2008 10:31:44 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE63GKovwdCZ for ; Wed, 12 Mar 2008 10:31:08 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP for ; Wed, 12 Mar 2008 10:31:08 -0400 (EDT) Received: from [10.0.8.42] ([10.0.8.42]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008031210291041-10461 ; Wed, 12 Mar 2008 10:29:10 -0400 Message-ID: <47D7E966.2050402@certicom.com> Date: Wed, 12 Mar 2008 10:32:06 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 03/12/2008 10:29:10 AM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 03/12/2008 10:29:44 AM, Serialize complete at 03/12/2008 10:29:44 AM Subject: [IPsec] Negotiation of Transport Mode Behind NAT in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This question is related to Scott Moonen's question "Questions regarding NAT traversal in IKEv2" (dated 23/08/2007). I quote > I'll phrase my question in terms of the following configuration, with > a NAT in front of the initiator, and with the establishment of a > transport mode SA; other configurations are possible: > [initiator@A]--[NAT@X]----------------[responder@Y] > The initiator's private address is A and its public address is X. The > responder's address is Y. The above RFC text requires the initiator > to supply A for TSi and Y for TSr; this also makes perfect sense > knowing that the initiator's SPD uses address pair (A, Y), and the > that the initiator properly has no knowledge of X. As asked by him and answered by draft draft-kukec-ikev2-tutorial-additions-02 (page 19) and specified by RFC46, the original IP (address A) in the TS should be used to do incremental checksum. However, this incremental checksum can only be done by 1 side: the one that has both the original IP and the NAT IP. Furthermore, this is not sufficient if there are 2 NAT devices. This is why in the IKEv1 RFC 3947, there are 2 NAT-OA payloads (NAT-OAi and NAT-OAr). So you really can't do incremental checksum with transport mode NAT in IKEv2. (However, you can always fall back on full checksumming.) But the main gist of my question is that you can't negotiate transport mode with (A,Y) either. As Scott noted, Y sees packets from X, not A. So it seems to me that with a TS of (A, Y), Y will reject decrypted packets from X and bypass packets destined for X since they do not match (A, Y). In fact, consider the possible TSi, TSr values of the following devices that are both behind NAT. a -- X ----- Y -- b The choices are TSi = [a, X, *], TSr = [b, Y, *] [I]nitiator a [R]esponder b TSi = a -> R cannot use* TSr = a -> R cannot use TSi = X -> I cannot see TSi = X -> I cannot use TSi = * -> ok TSi = * -> ok TSr = b -> I cannot see TSr = b -> I cannot use TSr = Y -> R cannot use TSr = Y -> R cannot use TSr = * -> ok TSr = * -> ok * Because device does not use that address as source or does not use as destination. In a nutshell, the use of private IP in TS means one side cannot use because it sends _to_ the NAT. The use of NAT IP in TS means one side cannot use because it sends _from_ the private IP. Only a TSi/TSr = */* request and response generate the matching SP. But that would mean all packets to everywhere are encrypted, unless each side locally narrows the TS. If someone has some insight about this, that would be great. One solution I can think of is this: Initiator a sends TSi = ((a), (*)), TSr = ((Y), (*)). Responder b sends back TSi = ((a), (X)), TSr = ((Y), (b)). That is, a sends the 2 IPs as a sees them + an all selector. Responder b echos back the 2 IPs and replaces the all with the 2 IPs that b sees. The combination TSi = ((a), (X)), TSr = ((Y), (b)) matches packets that a sends (a, Y) and that b sends (X, b). The downside is that the other 3 combinations are not used. (If the TS are converted to SP, then there are 8 SPs, 4 out 4 in, and 6 are not "used"). Note that if there are no NATs, then a requests TSi = ((a), (*)), TSr = ((b), (*)) and b responds TSi = ((a), (a)), TSr = ((b), (b)) (or more simply TSi = (a), TSr = (b)) which is as expected. This will also work if there is 1 NAT device. As a bonus, the combination TSi = ((a), (X)), TSr = ((Y), (b)) means that both sides have access to both "NAT-OAi" and "NAT-OAr" and can do incremental checksum. Chinh -- http://www.certicom.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From facfoxylovecej@foxylove.net Sun Mar 16 04:17:11 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D210928C20F; Sun, 16 Mar 2008 04:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.536 X-Spam-Level: **** X-Spam-Status: No, score=4.536 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, INVALID_DATE=1.245, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOXlogyrrozO; Sun, 16 Mar 2008 04:17:11 -0700 (PDT) Received: from [195.128.252.106] (unknown [195.138.193.172]) by core3.amsl.com (Postfix) with ESMTP id AE18F28C321; Sun, 16 Mar 2008 04:17:05 -0700 (PDT) Received: from [195.128.252.106] by mail.foxylove.net; , 16 Mar 2008 13:14:49 +0200 Date: , 16 Mar 2008 13:14:49 +0200 From: "Fernando Mills" X-Mailer: The Bat! (v2.00.6) Personal Reply-To: facfoxylovecej@foxylove.net X-Priority: 3 (Normal) Message-ID: <710921366.41301819111540@foxylove.net> To: agentx-archive@lists.ietf.org Subject: Software MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------D31FB25018FB2CD" ------------D31FB25018FB2CD Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Looking for the better pricein software discounts? Now you'll catch the opportunity to use the software equipment you want from long time. And the best thing for you is, all softs are awfully cheap. Check up by yourself and take the softwares for lowest rates ever seen! http://maryannlingardpp592.blogspot.com ------------D31FB25018FB2CD Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: 7bit
Looking for the better pricein software discounts?
Now you'll catch the opportunity to use the software equipment you want from long time.
And the best thing for you is, all softs are awfully cheap.
Check up by yourself and take the softwares for lowest rates ever seen!
http://maryannlingardpp592.blogspot.com ------------D31FB25018FB2CD-- From ipsec-bounces@ietf.org Sun Mar 16 08:03:43 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C762528C378; Sun, 16 Mar 2008 08:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.513 X-Spam-Level: X-Spam-Status: No, score=-100.513 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmJfdIc8IChp; Sun, 16 Mar 2008 08:03:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866133A6CCA; Sun, 16 Mar 2008 08:03:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51FB3A6CCA for ; Sun, 16 Mar 2008 08:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mp9zV1wDRk6 for ; Sun, 16 Mar 2008 08:03:24 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C52E028C39D for ; Sun, 16 Mar 2008 08:01:56 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2BADD294004; Sun, 16 Mar 2008 17:06:02 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8C67D294003 for ; Sun, 16 Mar 2008 17:06:01 +0200 (IST) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m2GExdfU004676 for ; Sun, 16 Mar 2008 16:59:39 +0200 (IST) Message-Id: <22520736-FD6B-4CB1-9A84-E368A6C4B218@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 16 Mar 2008 16:59:38 +0200 References: <20080316144501.941303A6D62@core3.amsl.com> X-Mailer: Apple Mail (2.919.2) Subject: [IPsec] Fwd: I-D Action:draft-nir-qcr-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2142289771==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2142289771== Content-Type: multipart/alternative; boundary=Apple-Mail-26--260887727 --Apple-Mail-26--260887727 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello all The draft below describes a problem that IMO delays crash recovery in IKEv2. It also proposes a solution. Please send comments to the list and/or directly to me. Yoav Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 16, 2008 4:45:01 PM GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nir-qcr-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Quick Crash Recovery Method for IKE > Author(s) : Y. Nir > Filename : draft-nir-qcr-00.txt > Pages : 12 > Date : 2008-03-16 > > This document describes an extension to the IKEv2 protocol that > allows for faster crash recovery using a saved token method. > > When an IPsec tunnel between two IKEv2 implementations is > disconnected due to a restart of one peer, it can take as much as > several minutes to recover. In this text we propose an extension to > the protocol, that allows for recovery within a few seconds of the > reboot. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-qcr-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Scanned by Check Point Total Security Gateway. --Apple-Mail-26--260887727 Content-Type: multipart/mixed; boundary=Apple-Mail-27--260887727 --Apple-Mail-27--260887727 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello all

The draft below describes = a problem that IMO delays crash recovery in IKEv2. It also proposes a = solution.

Please send comments to = the list and/or directly to me.

Yoav

Begin = forwarded message:

Date: March 16, 2008 4:45:01 PM = GMT+02:00
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-nir-qcr-00.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

Title =           : A Quick = Crash Recovery Method for IKE
Author(s) =       : Y. Nir
Filename =        : = draft-nir-qcr-00.txt
Pages =           : = 12
= Date =            : = 2008-03-16

This document describes an extension to the IKEv2 = protocol that
allows for faster crash recovery using a saved token = method.

When an IPsec tunnel between two IKEv2 implementations = is
disconnected due to a restart of one peer, it can take as much = as
several minutes to recover.  In this text we propose an = extension to
the protocol, that allows for recovery within a few = seconds of the
reboot.

A URL for this Internet-Draft is:
http://w= ww.ietf.org/internet-drafts/draft-nir-qcr-00.txt

Internet-Draft= s are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-27--260887727 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-03-16073519.I-D@ietf.org>

--Apple-Mail-27--260887727 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Scanned by Check Point Total Security Gateway.

--Apple-Mail-27--260887727-- --Apple-Mail-26--260887727-- --===============2142289771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============2142289771==-- From cbocustody@espicom.com Mon Mar 17 02:00:30 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3D23A6E11; Mon, 17 Mar 2008 02:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.011 X-Spam-Level: *** X-Spam-Status: No, score=3.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9DH-DLY2TIi; Mon, 17 Mar 2008 02:00:29 -0700 (PDT) Received: from espicom.com (unknown [59.96.89.28]) by core3.amsl.com (Postfix) with SMTP id 64F983A6E1D; Mon, 17 Mar 2008 02:00:24 -0700 (PDT) Received: from nikhil [198.33.146.146] (port=22112 helo=nikhil) by 340e5f3bespicom.com with ESMTP id 684420161033 for ; Mon, 17 Mar 2008 14:28:15 +0530 Message-ID: <001b01c8883b$23000130$06962cdc@nikhil> From: Chasity To: imapext-archive@lists.ietf.org Subject: It dash Date: Mon, 17 Mar 2008 14:28:15 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C8883B.23000130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.2869 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.1081 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C8883B.23000130 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable communications and now we have the technology to accomplish it. prompts are still essential to their intellectual growth. = strengths of information highways as communication mediums will ------=_NextPart_000_0018_01C8883B.23000130 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
immense that society may form into a single entity, a global

=

C A 2N A D/2AN     P 5 6H A RM A 3CY

V/A \G _RA - $1.42
C 3/ A L / S - $2.25
S1 O M A - $0.61
L E1 V / T R A - $3.69
FEMALE V/AG\ R -A - $1.51
U 9 L T 4R A M - $1.36
176 Items on Sale Today.

the mind of the artists. Artists would not have complete control
= ------=_NextPart_000_0018_01C8883B.23000130-- From zifgiumarelloscop@giumarellos.com Tue Mar 18 14:04:45 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E55A3A67F2; Tue, 18 Mar 2008 14:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.995 X-Spam-Level: **** X-Spam-Status: No, score=4.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR5kNon6sywz; Tue, 18 Mar 2008 14:04:43 -0700 (PDT) Received: from coopcastilla.telesat.net.co (coopcastilla.telesat.net.co [66.128.40.249]) by core3.amsl.com (Postfix) with ESMTP id D689128C1DA; Tue, 18 Mar 2008 14:04:39 -0700 (PDT) Received: from [66.128.40.249] by mx4.mysuperpageshosting.com; Tue, 18 Mar 2008 16:02:22 -0500 Date: Tue, 18 Mar 2008 16:02:22 -0500 From: "Bernadette Caudill" X-Mailer: The Bat! (v3.51.10) Professional Reply-To: zifgiumarelloscop@giumarellos.com X-Priority: 3 (Normal) Message-ID: <577587542.62293792663114@giumarellos.com> To: agentx-archive@lists.ietf.org Subject: Software MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------D38DABBB48DA4F21" X-Antivirus: avast! (VPS 080318-1, 18/03/2008), Outbound message X-Antivirus-Status: Clean ------------D38DABBB48DA4F21 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Are you searhing for the better prices in software discounts? Now you will get the chance to use the softs you dreamt of for a very long time. And the better thing for you is, all softs are of awfully low prices. Be sure by youself and take the softwares for cheapest rates ever seen! http://annmarierooneyn177.blogspot.com ------------D38DABBB48DA4F21 Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: 7bit
Are you searhing for the better prices in software discounts?
Now you will get the chance to use the softs you dreamt of for a very long time.
And the better thing for you is, all softs are of awfully low prices.
Be sure by youself and take the softwares for cheapest rates ever seen!
http://annmarierooneyn177.blogspot.com ------------D38DABBB48DA4F21-- From ipsec-bounces@ietf.org Wed Mar 19 10:21:37 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF28828C291; Wed, 19 Mar 2008 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYlAYB0ClSRs; Wed, 19 Mar 2008 10:21:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38E83A6F66; Wed, 19 Mar 2008 10:21:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0DE28C4E9 for ; Wed, 19 Mar 2008 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ4L8usJq5Jy for ; Wed, 19 Mar 2008 10:21:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 58E4A28C6C5 for ; Wed, 19 Mar 2008 10:20:41 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 46C79294006; Wed, 19 Mar 2008 19:24:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A7A01294001 for ; Wed, 19 Mar 2008 19:24:49 +0200 (IST) Received: from [91.90.139.73] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m2JHI7fU008670 for ; Wed, 19 Mar 2008 19:18:07 +0200 (IST) Message-ID: <47E14ACC.5030400@checkpoint.com> Date: Wed, 19 Mar 2008 19:18:04 +0200 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: multipart/mixed; boundary="------------000209050805050108010003" Subject: [IPsec] [Fwd: I-D Action:draft-sheffer-ipsec-failover-03.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols 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. --------------000209050805050108010003 Content-Type: multipart/alternative; boundary="------------000700020407000101040507" --------------000700020407000101040507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is a belated submission following a meeting in Vancouver. We have made significant changes to the DOS-resistance properties of the protocol. As always, comments are requested and welcome. Yaron -------- Original Message -------- Subject: I-D Action:draft-sheffer-ipsec-failover-03.txt Date: Wed, 19 Mar 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPsec Gateway Failover Protocol Author(s) : Y. Sheffer, et al. Filename : draft-sheffer-ipsec-failover-03.txt Pages : 25 Date : 2008-03-19 The Internet Key Exchange version 2 (IKEv2) protocol has computational and communication overhead with respect to the number of round-trips required and cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol is used for authentication, which adds several more round trips and therefore latency. To re-establish security associations (SA) upon a failure recovery condition is time consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In many failure cases it would be useful to provide an efficient way to resume an interrupted IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected, or alternatively migrate to another gateway that is associated with the previous one. The proposed approach conveys IKEv2 state information, in the form of an encrypted ticket, to a VPN client that is later presented to the VPN gateway for re-authentication. The encrypted ticket can only be decrypted by the VPN gateway in order to restore state for faster session setup. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-failover-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------000700020407000101040507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

This is a belated submission following a meeting in Vancouver. We have made significant changes to the DOS-resistance properties of the protocol.


As always, comments are requested and welcome.


    Yaron


-------- Original Message --------
Subject: I-D Action:draft-sheffer-ipsec-failover-03.txt
Date: Wed, 19 Mar 2008 10:15:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IPsec Gateway Failover Protocol
	Author(s)       : Y. Sheffer, et al.
	Filename        : draft-sheffer-ipsec-failover-03.txt
	Pages           : 25
	Date            : 2008-03-19

The Internet Key Exchange version 2 (IKEv2) protocol has
computational and communication overhead with respect to the number
of round-trips required and cryptographic operations involved.  In
remote access situations, the Extensible Authentication Protocol is
used for authentication, which adds several more round trips and
therefore latency.

To re-establish security associations (SA) upon a failure recovery
condition is time consuming, especially when an IPsec peer, such as a
VPN gateway, needs to re-establish a large number of SAs with various
end points.  A high number of concurrent sessions might cause
additional problems for an IPsec peer during SA re-establishment.

In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session.  This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA
with a gateway in a highly efficient manner, utilizing a previously
established IKE SA.

A client can reconnect to a gateway from which it was disconnected,
or alternatively migrate to another gateway that is associated with
the previous one.  The proposed approach conveys IKEv2 state
information, in the form of an encrypted ticket, to a VPN client that
is later presented to the VPN gateway for re-authentication.  The
encrypted ticket can only be decrypted by the VPN gateway in order to
restore state for faster session setup.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-failover-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------000700020407000101040507-- --------------000209050805050108010003 Content-Type: Message/External-body; name="draft-sheffer-ipsec-failover-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-sheffer-ipsec-failover-03.txt" Content-Type: text/plain Content-ID: <2008-03-19100334.I-D@ietf.org> --------------000209050805050108010003 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --------------000209050805050108010003-- From ipsec-bounces@ietf.org Thu Mar 20 07:15:43 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E8328C5CA; Thu, 20 Mar 2008 07:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.514 X-Spam-Level: X-Spam-Status: No, score=-100.514 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuodyd89S+cD; Thu, 20 Mar 2008 07:15:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849C13A6CD0; Thu, 20 Mar 2008 07:15:31 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093C13A69A3 for ; Thu, 20 Mar 2008 07:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z01fGNqC2b56 for ; Thu, 20 Mar 2008 07:15:21 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id D68CB28C3AB for ; Thu, 20 Mar 2008 07:15:20 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 54F7C10027FE4 for ; Thu, 20 Mar 2008 10:13:02 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eYM3MLxsfPX for ; Thu, 20 Mar 2008 10:12:56 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP for ; Thu, 20 Mar 2008 10:12:56 -0400 (EDT) Received: from [10.0.8.48] ([10.0.8.48]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008032010112686-55367 ; Thu, 20 Mar 2008 10:11:26 -0400 Message-ID: <47E27145.70503@certicom.com> Date: Thu, 20 Mar 2008 10:14:29 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 03/20/2008 10:11:26 AM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 03/20/2008 10:11:28 AM, Serialize complete at 03/20/2008 10:11:28 AM Subject: [IPsec] Obsolete Statements in RFC4306 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Given this clarification in rfc 4718: << Moreover, the combination of ESP and AH (between the same endpoints) had already become largely obsolete in 1998 when RFC 2406 was published. Our recommendation is that IKEv2 implementations should not support this combination, and implementers should not assume the combination can be made to work in an interoperable manner. >> Are the following statements obsolete in rfc 4306: << IKE can also negotiate use of IP Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. >> should be "ESP or AH SA" << When SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPComp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be deleted together. >> should be "first with IPComp, then with ESP or AH" << If two successive structures have the same Proposal number, it means that the proposal consists of the first structure AND the second. So a proposal of AH AND ESP would have two proposal structures, one for AH and one for ESP and both would have Proposal #1. >> (In fact, support for proposals with same number not necessary at all. The only other usage I can think of, IPCOMP, is now a NOTIFY payload). Chinh -- http://www.certicom.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From SamwherewithRiley@verizonwireless.com Sat Mar 22 04:35:43 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11BAA3A6D87; Sat, 22 Mar 2008 04:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.122 X-Spam-Level: X-Spam-Status: No, score=-13.122 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HOST_EQ_MODEMCABLE=1.368, HOST_MISMATCH_COM=0.311, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SUB_PROVEN=0.618, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci-dqNPfeG2K; Sat, 22 Mar 2008 04:35:42 -0700 (PDT) Received: from lbedroom.sharpe (cpc2-sout4-0-0-cust895.sotn.cable.ntl.com [86.7.71.128]) by core3.amsl.com (Postfix) with SMTP id BCCD73A6C32; Sat, 22 Mar 2008 04:35:41 -0700 (PDT) Received: from 17630591049110570.19788597722870591.12751071172734779.15821667495219798 (HELO localhost.localdomain) (17351785364965277.12227381250600802.10455933919366005.19348017106887725) by 19036613608729380.14084143177435581.13154541030338048.13408847322516201 with SMTP; Sat, 22 Mar 2008 11:33:06 +0000 Date: Sat, 22 Mar 2008 11:33:06 +0000 Message-Id: <0IX193EJXVWDA035@verizonwireless.com> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 301623 X-Header-Versions: Hewlett-Packard.3t2bn3nd4.fk@us.newsgram.hp.com X-FID: 85E32DBC-7808-56AF-B4E7-63CDEA42DCB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Cc: , , , From: "Gilbert Austin" Subject: Proven Effective for 72 Hours. Gain An Amazing 1 to 3 full Inches... See my pictures as proof!!! http://Mevelatones.com/ From ipsec-bounces@ietf.org Thu Mar 27 15:17:07 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD6728C966; Thu, 27 Mar 2008 15:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.977 X-Spam-Level: X-Spam-Status: No, score=-100.977 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bt5vIf026Kr; Thu, 27 Mar 2008 15:17:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C32328C928; Thu, 27 Mar 2008 15:17:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48E128C8EA for ; Thu, 27 Mar 2008 15:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WcqAdR5rmRY for ; Thu, 27 Mar 2008 15:17:00 -0700 (PDT) Received: from omzesmtp03a.verizonbusiness.com (omzesmtp03a.verizonbusiness.com [199.249.25.201]) by core3.amsl.com (Postfix) with ESMTP id D5A3728C906 for ; Thu, 27 Mar 2008 15:16:59 -0700 (PDT) Received: from pmismtp05.wcomnet.com ([166.37.158.165]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007)) with ESMTP id <0JYE00162TS9R100@firewall.verizonbusiness.com> for ipsec@ietf.org; Thu, 27 Mar 2008 22:14:34 +0000 (GMT) Received: from pmismtp05.wcomnet.com ([127.0.0.1]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JYE00HSDTS9FP@pmismtp05.mcilink.com> for ipsec@ietf.org; Thu, 27 Mar 2008 22:14:33 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JYE00H74TS7L4@pmismtp05.mcilink.com> for ipsec@ietf.org; Thu, 27 Mar 2008 22:14:33 +0000 (GMT) Received: from ASHEVS011.mcilink.com ([153.39.69.138]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 22:14:30 +0000 Date: Thu, 27 Mar 2008 22:14:28 +0000 From: "Snyder, Guy" To: ipsec@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: IKEv2 Interoperability Workshop IV - 2008 Registration Thread-index: AciQV+y0ZhW/DrrlRpKU/SczVGlJag== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Mar 2008 22:14:30.0153 (UTC) FILETIME=[ED84FF90:01C89057] Subject: [IPsec] IKEv2 Interoperability Workshop IV - 2008 Registration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0789726846==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0789726846== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C89057.ECCF0F35" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C89057.ECCF0F35 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ICSA Labs IKEv2 Interoperability Workshop IV - 2008 Registration 19-23 May 2008 San Antonio, Texas Holiday Inn Riverwalk 217 North St. Mary's Street San Antonio, TX 78205 210-224-2500 (Ask for IKEv2 Interoperability Workshop IV rate) http://www.ichotelsgroup.com/h/d/hi/1/en/cwshome/DPRD-7D4NPZ/SATRW More Information=20 Technical & Logistics Plans - Guy Snyder, VPN Programs Manager, at 717.790.8142 email - Guy.snyder@icsalabs.com Pricing and Registration - Harry Brittain, Vendor Services Manager at 717.790.8111 email - hbrittain@icsalabs.com =20 Link to ICSA Labs IKEv2 Interoperability Workshop IV - Current Information =20 http://www.icsalabs.com/icsa/topic.php?tid=3D08fa$3f857204-7dddfb77$48e3-= 1 26bade0 =20 =20 Regards, =20 Guy Snyder VPN Programs Manager ICSA Labs ph: 717.790.8142 fax: 717.790.8170 guy.snyder@icsalabs.com =20 http://www.icsalabs.com =20 =20 =20 ------_=_NextPart_001_01C89057.ECCF0F35 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ICSA Labs IKEv2 Interoperability Workshop IV - 2008 = Registration

19-23 May 2008

San Antonio, = Texas
Holiday Inn Riverwalk
217 North = St. Mary’s Street
San Antonio, = TX  78205
210-224-2500

(Ask for IKEv2 Interoperability Workshop IV = rate)

http://www.ichotelsgroup.com/h/d/hi/1/en/cwshome/DPRD-7D4NPZ/SATRW=

More Information =

Technical = & Logistics Plans - Guy Snyder, VPN Programs Manager, at 717.790.8142 = email - Guy.snyder@icsalabs.com

Pricing and Registration - Harry Brittain, Vendor Services Manager at 717.790.8111 = email – hbrittain@icsal= abs.com

 

Link to ICSA Labs IKEv2 Interoperability Workshop IV – Current = Information

 

http://www.icsalabs.com/icsa/topic.php?tid=3D08fa$3f857= 204-7dddfb77$48e3-126bade0

 

 

Regards,

 

Guy Snyder

VPN Programs Manager

ICSA Labs

ph:  717.790.8142

fax: 717.790.8170
guy.snyder@icsalabs.com
http://www.icsalabs.com

 

 

------_=_NextPart_001_01C89057.ECCF0F35-- --===============0789726846== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0789726846==-- From ipsec-bounces@ietf.org Fri Mar 28 06:55:21 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A95128C91A; Fri, 28 Mar 2008 06:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.064 X-Spam-Level: X-Spam-Status: No, score=-101.064 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9VEz7DyhZr1; Fri, 28 Mar 2008 06:55:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D0C28C96B; Fri, 28 Mar 2008 06:54:40 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E2C3A67E6 for ; Fri, 28 Mar 2008 06:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZzX6e5XSPLD for ; Fri, 28 Mar 2008 06:54:37 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 7A60828C91A for ; Fri, 28 Mar 2008 06:54:22 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2SDuBFq018988; Fri, 28 Mar 2008 08:56:22 -0500 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Mar 2008 15:54:05 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Mar 2008 15:54:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 15:54:06 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7238E9A9@vaebe104.NOE.Nokia.com> In-Reply-To: <22520736-FD6B-4CB1-9A84-E368A6C4B218@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Fwd: I-D Action:draft-nir-qcr-00.txt thread-index: AciHdqQVJNpiUgAhSIKEDdgidoHcVAJY+b1Q References: <20080316144501.941303A6D62@core3.amsl.com> <22520736-FD6B-4CB1-9A84-E368A6C4B218@checkpoint.com> From: To: , X-OriginalArrivalTime: 28 Mar 2008 13:54:05.0160 (UTC) FILETIME=[2FA46680:01C890DB] X-Nokia-AV: Clean Subject: Re: [IPsec] Fwd: I-D Action:draft-nir-qcr-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yoav, An interesting idea! I haven't really reviewed the details, but I have one small comment: there's no such thing as an unprotected informational exchange in IKEv2. There's only a one-way unprotected notification, but it's never replied to (see RFC 4306, Section 1.5). Best regards, Pasi -----Original Message----- > From: Yoav Nir > Sent: 16 March, 2008 17:00 > To: ipsec@ietf.org > Subject: [IPsec] Fwd: I-D Action:draft-nir-qcr-00.txt > > Hello all > > The draft below describes a problem that IMO delays crash recovery > in IKEv2. It also proposes a solution. > > Please send comments to the list and/or directly to me. > > Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 28 13:46:45 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD0E3A6E58; Fri, 28 Mar 2008 13:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5rATO+5koY1; Fri, 28 Mar 2008 13:46:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788FB3A6BAA; Fri, 28 Mar 2008 13:45:16 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CE43A69FD for ; Fri, 28 Mar 2008 13:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9t9tEO6HNdn for ; Fri, 28 Mar 2008 13:45:11 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7E5423A690D for ; Fri, 28 Mar 2008 13:45:10 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 024C8200BB7; Fri, 28 Mar 2008 23:45:08 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 70024200B92; Fri, 28 Mar 2008 23:45:08 +0300 (IDT) Received: from [172.31.21.214] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m2SKj7fU015238; Fri, 28 Mar 2008 23:45:08 +0300 (IDT) Message-Id: <4FE77840-2831-4815-86D1-C2205695F15C@checkpoint.com> From: Yoav Nir To: "" In-Reply-To: <1696498986EFEC4D9153717DA325CB7238E9A9@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 23:45:07 +0300 References: <20080316144501.941303A6D62@core3.amsl.com> <22520736-FD6B-4CB1-9A84-E368A6C4B218@checkpoint.com> <1696498986EFEC4D9153717DA325CB7238E9A9@vaebe104.NOE.Nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Fwd: I-D Action:draft-nir-qcr-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org OK. I will correct the terminology. The QCR_TOKEN in the unprotected notification does not get a reply anyway, so it's not a problem. I also plan to make some other changes: - change the name to something like draft-nir-ike-qcr... to avoid making it look like I'm inventing a whole new thing for the Internet - add discussion of session resumption (IFARE) because the IFARE people think it looks like it's a competing proposal - I thought of changing the name to QCD for quick crash Discovery, because the method really only buys you crash discovery. Recovery is done through a regular IKE exchange or through a low-resource IKE exchange using IFARE. On Mar 28, 2008, at 4:54 PM, wrote: > Hi Yoav, > > An interesting idea! > > I haven't really reviewed the details, but I have one small comment: > there's no such thing as an unprotected informational exchange in > IKEv2. There's only a one-way unprotected notification, but it's never > replied to (see RFC 4306, Section 1.5). > > Best regards, > Pasi > > -----Original Message----- >> From: Yoav Nir >> Sent: 16 March, 2008 17:00 >> To: ipsec@ietf.org >> Subject: [IPsec] Fwd: I-D Action:draft-nir-qcr-00.txt >> >> Hello all >> >> The draft below describes a problem that IMO delays crash recovery >> in IKEv2. It also proposes a solution. >> >> Please send comments to the list and/or directly to me. >> >> Yoav > > Scanned by Check Point Total Security Gateway. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec