From latten@austin.ibm.com Thu Jul 1 11:27:03 2010 Return-Path: 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 DE1933A67F9 for ; Thu, 1 Jul 2010 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] 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 WbkQ1SjOzp1j for ; Thu, 1 Jul 2010 11:27:03 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 169B03A67A3 for ; Thu, 1 Jul 2010 11:27:02 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o61IJdbB008780 for ; Thu, 1 Jul 2010 12:19:39 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o61IRC4Y218866 for ; Thu, 1 Jul 2010 12:27:13 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o61IR3VZ001074 for ; Thu, 1 Jul 2010 12:27:03 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o61IR34f000871 for ; Thu, 1 Jul 2010 12:27:03 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id o61IR2GB038548 for ; Thu, 1 Jul 2010 13:27:03 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.3/8.14.3) with ESMTP id o61I2Ktl011713 for ; Thu, 1 Jul 2010 13:02:20 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.3/8.14.3/Submit) id o61I2KEe011711 for ipsec@ietf.org; Thu, 1 Jul 2010 13:02:20 -0500 From: Joy Latten Message-Id: <201007011802.o61I2KEe011711@faith.austin.ibm.com> Date: Thu, 01 Jul 2010 13:02:20 -0500 To: ipsec@ietf.org User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPsec] Question about AUTH payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:27:04 -0000 I have a question about RESERVED field and its influence on AUTH payload. Suppose responder sends and IKE_AUTH message whose IDr payload has 1's in the RESERVED field instead of 0's. (I know rfc says no to this, but this is in regards to an IKEv2 TAHI testcase that tests implementation's response to receiving 1's in RESERVED fields of IKE_AUTH message.) I understand that in section 2.5 it states, "Also for forward compatibility, all fields marked RESERVED MUST be set to zero by an implementation running version 2.0, and their content MUST be ignored by an implementation running version 2.0 ("Be conservative in what you send and liberal in what you receive")." However, when computing the AUTH payload in the IKE_AUTH message, the value prf(SK_pr, IDr) will be appended. ikev2bis breaks this down in section 2.15, ResponderIDPayload = PayloadHeader | RestOfRespIDPayload RestOfRespIDPayload = IDType | RESERVED | RespIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload) I am thinking it can be concluded that responder computed MACedIDForR with 1's in the RESERVED field. My confusion is how should initiator handle this? When section 2.5 says "content MUST be ignored", I am not sure how to interpret because the RESERVED field is now part of the MAC. Initiator needs to compute MACedIDForR to verify the MACedIDForR he received from responder. Should he use the IDr payload responder sent with 1's in RESERVED field? Or does "ignoring content" of RESERVED field mean initiator can safely assume/build the IDr payload using 0's for RESERVED field when he computes MACedIDForR? Of course in this case the authentication will fail... would that be expected behaviour? Thanks for any clarification. regards, Joy Latten From dan.mcdonald@oracle.com Thu Jul 1 11:37:12 2010 Return-Path: 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 760983A68A0 for ; Thu, 1 Jul 2010 11:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 XNaNo4oqbqoN for ; Thu, 1 Jul 2010 11:37:11 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8847C3A67F9 for ; Thu, 1 Jul 2010 11:37:11 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o61IanKk013762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jul 2010 18:36:51 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o61FWZaa000400; Thu, 1 Jul 2010 18:36:49 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 375033961278009322; Thu, 01 Jul 2010 11:35:22 -0700 Received: from kebe.East.Sun.COM (/129.148.174.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jul 2010 11:35:22 -0700 Date: Thu, 1 Jul 2010 14:35:10 -0400 From: Dan McDonald To: Joy Latten Message-ID: <20100701183510.GG29084@kebe.East.Sun.COM> References: <201007011802.o61I2KEe011711@faith.austin.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007011802.o61I2KEe011711@faith.austin.ibm.com> Organization: Oracle - Solaris Security (hon. Networking) User-Agent: Mutt/1.5.20 (2009-06-14) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C2CE041.00B8:SCFMA4539814,ss=1,fgs=0 Cc: ipsec@ietf.org Subject: Re: [IPsec] Question about AUTH payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:37:12 -0000 On Thu, Jul 01, 2010 at 01:02:20PM -0500, Joy Latten wrote: > I am thinking it can be concluded that responder computed MACedIDForR with > 1's in the RESERVED field. That seems valid (though clearly the implementation who sends 1s is violating Postel's Law, but you did say it's a TAHI test...). > Initiator needs to compute MACedIDForR to verify the MACedIDForR > he received from responder. Should he use the IDr payload responder sent > with 1's in RESERVED field? Yes, that's how I interpreted it. You can't rewrite bits that are fed into an off-the-wire authentication calculation. > Or does "ignoring content" of RESERVED field mean initiator > can safely assume/build the IDr payload using 0's for RESERVED field > when he computes MACedIDForR? Of course in this case the authentication > will fail... would that be expected behaviour? Postel's Law ("Be conservative in what you send, be liberal in what you receive.") would suggest you compute the authentication with the EXACT contents of what was on the wire. Dan From mcins1@gmail.com Fri Jul 2 07:36:43 2010 Return-Path: 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 BD4E13A67B2 for ; Fri, 2 Jul 2010 07:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 yNEqXK-4muJb for ; Fri, 2 Jul 2010 07:36:42 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9F44A3A67A4 for ; Fri, 2 Jul 2010 07:36:42 -0700 (PDT) Received: by fxm1 with SMTP id 1so2596746fxm.31 for ; Fri, 02 Jul 2010 07:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=aEvtWzecfcTylfuGOaEzd4hm9DjWXXciumMBZX1pnsE=; b=PFetz5+7r4fb23KsW/fW/qn08MoV0RIdBzZQ7BkqbF9eRVnXEJDIHCV7AXQLhePhce uUn5vQ8S6tk0yFhS/QWxBItoWBZZ/ShLG7nLhQopoipkvUL9ix3Qi0AqZAV8vfmZOT/2 XZLs+7oUcJsxurK41Qo0HlBKSArlhlP/jkTGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=b8H69vSWH3BUVvl+tQJ+hC0R9C1HmA7BBuTZmb5oYVzdORk7Na5Ik4xG94fEO3eWUD wv+vgtpF72tz0eGBHlvvDoDg0FLybMrZzafRtiW9Txsm6cYQtLX+h4+wQaa+e5wtHgX3 Uglil4zFVjhMyuqtPBrgyJf4W0CVSNSK27DcA= Received: by 10.103.177.5 with SMTP id e5mr189392mup.15.1278081410281; Fri, 02 Jul 2010 07:36:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.8.15 with HTTP; Fri, 2 Jul 2010 07:36:30 -0700 (PDT) From: Matthew Cini Sarreo Date: Fri, 2 Jul 2010 16:36:30 +0200 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636416c7d7431b2048a688422 Subject: [IPsec] [IKE] Mode config IV calculations X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 14:36:43 -0000 --001636416c7d7431b2048a688422 Content-Type: text/plain; charset=ISO-8859-1 Hello all, Recently I looked into the IKE Config Mode drafts and ran into an ambiguity problem. Config Mode (draft 05) section 3.1.1 states: The derivation of the initialization vector (IV) for the first message, used with SKEYID_e to encrypt the message, is described in Appendix B of [IKE]. Subsequent IVs are taken from the last ciphertext block of the previous message as described in [IKE]. In IKE Appendix B, two methods for IV calculation are available; one for Phase 1 and another for Phase 2. As Config Mode is neither but something in between, it feels like the comment referring to Appendix B leaves much to interpretation. In fact, I checked some implementations and stumbled into ones that use both methods for Config Mode exchanges; this obviously created some interoperability issues. I am inclined to think that the Phase 2 method is supposed to be used due to the fact that the resulting hash is derived using the incoming packet's message ID. Is this correct, or are implementations allowed to use any one of the methods? If Config Mode is supposed to use Phase 2 calculations for this (or maybe some other reasoning), some implementations out there seem to have huge interoperability issues (due to an incorrect IV calculation method use). Would really appreciate if anyone could shed some light on this. Regards, Matt --001636416c7d7431b2048a688422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,

Recently I looked into the IKE Config Mode drafts and ran= into an ambiguity problem.

Config Mode (draft 05) section 3.1.1 sta= tes:

The derivation of the initialization vector (IV) for the first = message, used with SKEYID_e to encrypt the message, is described in Appendi= x B of [IKE].=A0 Subsequent IVs are taken from the last ciphertext block of= the previous message as described in [IKE].

In IKE Appendix B, two methods for IV calculation are available; one fo= r Phase 1 and another for Phase 2.

As Config Mode is neither but so= mething in between, it feels like the comment referring to Appendix B leave= s much to interpretation. In fact, I checked some implementations and stumb= led into ones that use both methods for Config Mode exchanges; this obvious= ly created some interoperability issues.

I am inclined to think that the Phase 2 method is supposed to be used d= ue to the fact that the resulting hash is derived using the incoming packet= 's message ID. Is this correct, or are implementations allowed to use a= ny one of the methods? If Config Mode is supposed to use Phase 2 calculatio= ns for this (or maybe some other reasoning), some implementations out there= seem to have huge interoperability issues (due to an incorrect IV calculat= ion method use).

Would really appreciate if anyone could shed some light on this.
Regards,
Matt

--001636416c7d7431b2048a688422-- From latten@austin.ibm.com Fri Jul 2 08:24:04 2010 Return-Path: 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 155613A67B7 for ; Fri, 2 Jul 2010 08:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599] 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 lPuhyhxxIkHn for ; Fri, 2 Jul 2010 08:24:03 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id F26C33A6811 for ; Fri, 2 Jul 2010 08:24:02 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o62FEfdG022223 for ; Fri, 2 Jul 2010 09:14:41 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o62FO3WW124756 for ; Fri, 2 Jul 2010 09:24:03 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o62FO3LH024852 for ; Fri, 2 Jul 2010 09:24:03 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o62FO2K3024831; Fri, 2 Jul 2010 09:24:03 -0600 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id o62FO2GG033124; Fri, 2 Jul 2010 10:24:02 -0500 From: Joy Latten To: Dan McDonald In-Reply-To: <20100701183510.GG29084@kebe.East.Sun.COM> References: <201007011802.o61I2KEe011711@faith.austin.ibm.com> <20100701183510.GG29084@kebe.East.Sun.COM> Content-Type: text/plain Date: Fri, 02 Jul 2010 09:59:20 -0500 Message-Id: <1278082760.5121.1562.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] Question about AUTH payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 15:24:04 -0000 On Thu, 2010-07-01 at 14:35 -0400, Dan McDonald wrote: > On Thu, Jul 01, 2010 at 01:02:20PM -0500, Joy Latten wrote: > > > I am thinking it can be concluded that responder computed MACedIDForR with > > 1's in the RESERVED field. > > That seems valid (though clearly the implementation who sends 1s is violating > Postel's Law, but you did say it's a TAHI test...). > > > Initiator needs to compute MACedIDForR to verify the MACedIDForR > > he received from responder. Should he use the IDr payload responder sent > > with 1's in RESERVED field? > > Yes, that's how I interpreted it. You can't rewrite bits that are fed into > an off-the-wire authentication calculation. > > > Or does "ignoring content" of RESERVED field mean initiator > > can safely assume/build the IDr payload using 0's for RESERVED field > > when he computes MACedIDForR? Of course in this case the authentication > > will fail... would that be expected behaviour? > > Postel's Law ("Be conservative in what you send, be liberal in what you > receive.") would suggest you compute the authentication with the EXACT > contents of what was on the wire. > Ahh, ok. Good explanation! :-) Thanks! Guess I need to fix some code. :-) regards, Joy From wwwrun@core3.amsl.com Thu Jul 1 12:01:13 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 76BB928C165; Thu, 1 Jul 2010 12:01:13 -0700 (PDT) To: ynir@checkpoint.com From: IETF Secretariat Message-Id: <20100701190113.76BB928C165@core3.amsl.com> Date: Thu, 1 Jul 2010 12:01:13 -0700 (PDT) X-Mailman-Approved-At: Sat, 03 Jul 2010 08:22:26 -0700 Cc: tim.polk@nist.gov, paul.hoffman@vpnc.org, ipsec@ietf.org, turners@ieca.com, ipr-announce@ietf.org Subject: [IPsec] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ipsecme-ipsec-ha-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:01:13 -0000 Dear Yoav Nir: An IPR disclosure that pertains to your Internet-Draft entitled "IPsec Cluster Problem Statement" (draft-ietf-ipsecme-ipsec-ha) was submitted to the IETF Secretariat on 2010-07-01 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1345/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ipsecme-ipsec-ha-08." The IETF Secretariat From ynir@checkpoint.com Sun Jul 4 07:18:14 2010 Return-Path: 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 2D4C63A67E3 for ; Sun, 4 Jul 2010 07:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 AnXGM7T1yfs4 for ; Sun, 4 Jul 2010 07:18:13 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id C650E3A65A6 for ; Sun, 4 Jul 2010 07:18:12 -0700 (PDT) X-CheckPoint: {4C30A4E5-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o64EI8Dr011886; Sun, 4 Jul 2010 17:18:08 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 4 Jul 2010 17:18:39 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Sun, 4 Jul 2010 17:18:07 +0300 Thread-Topic: New Version Notification for draft-ietf-ipsecme-ipsec-ha-09 Thread-Index: Acsbg8wXXgMzpNRbQfaj9D8mMbTskQ== Message-ID: <9FBCCA7F-DBD5-47A7-BCEE-1B1949388E65@checkpoint.com> References: <20100704141523.82CCF3A6864@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FBCCA7FDBD547A7BCEE1B1949388E65checkpointcom_" MIME-Version: 1.0 Cc: Sean Turner Subject: [IPsec] Fwd: New Version Notification for draft-ietf-ipsecme-ipsec-ha-09 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 14:18:14 -0000 --_000_9FBCCA7FDBD547A7BCEE1B1949388E65checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. I've submitted version -09 of the draft. This has nothing to do with the recently-published IPR statement. It is abo= ut addressing last call comments from David Harrington. Yoav Begin forwarded message: From: IETF I-D Submission Tool > Date: July 4, 2010 5:15:22 PM GMT+03:00 To: Yoav Nir > Subject: New Version Notification for draft-ietf-ipsecme-ipsec-ha-09 A new version of I-D, draft-ietf-ipsecme-ipsec-ha-09.txt has been successfu= lly submitted by Yoav Nir and posted to the IETF repository. Filename: draft-ietf-ipsecme-ipsec-ha Revision: 09 Title: IPsec Cluster Problem Statement Creation_date: 2010-07-04 WG ID: ipsecme Number_of_pages: 13 Abstract: This document defines terminology, problem statement and requirements for implementing IKE and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled, in order to allow peers to interoperate with clusters from different vendors. An agreed terminology, problem statement and requirements will allow IETF working gropus to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. The IETF Secretariat. Scanned by Check Point Total Security Gateway. --_000_9FBCCA7FDBD547A7BCEE1B1949388E65checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi.

I'v= e submitted version -09 of the draft.

This has not= hing to do with the recently-published IPR statement. It is about addressin= g last call comments from David Harrington.

Yoav

Begin forwarded message:

From: IETF I-D Sub= mission Tool <idsubmission@ietf= .org>
Date: July 4, 2010 5:15:22= PM GMT+03:00
To: Yoav Nir <ynir@checkpoint.com>
Subject: New Version Notification for draft-ietf-ip= secme-ipsec-ha-09


A new version of I-D, d= raft-ietf-ipsecme-ipsec-ha-09.txt has been successfully submitted by Yoav N= ir and posted to the IETF repository.

Filename: draft-ietf-ipsecme-ipsec-haRevision: = 09
Title: IPsec = Cluster Problem Statement
Creation_date: 2010-07-04
WG ID: ipsecme
Number_of_pages: 13

Ab= stract:
This document defines terminology, problem statement and require= ments
for implementing IKE and IPsec on clusters.  It also describe= s gaps
in existing standards and their implementation that need to befilled, in order to allow peers to interoperate with clusters from
diff= erent vendors.  An agreed terminology, problem statement and
requir= ements will allow IETF working gropus to consider development
of IPsec/I= KEv2 mechanisms to simplify cluster implementations.



The IET= F Secretariat.



Scanned by Check Point Total Security Gateway= .

= --_000_9FBCCA7FDBD547A7BCEE1B1949388E65checkpointcom_-- From root@core3.amsl.com Sun Jul 4 07:30:02 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B9193A67E5; Sun, 4 Jul 2010 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100704143001.9B9193A67E5@core3.amsl.com> Date: Sun, 4 Jul 2010 07:30:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 14:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IPsec Cluster Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-09.txt Pages : 13 Date : 2010-07-04 This document defines terminology, problem statement and requirements for implementing IKE and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled, in order to allow peers to interoperate with clusters from different vendors. An agreed terminology, problem statement and requirements will allow IETF working gropus to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-09.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ipsec-ha-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-04071521.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Sun Jul 4 07:54:59 2010 Return-Path: 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 E3BD33A6818 for ; Sun, 4 Jul 2010 07:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 PlBn6Y5RAPbH for ; Sun, 4 Jul 2010 07:54:59 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 05E123A680E for ; Sun, 4 Jul 2010 07:54:58 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o64Esva9005268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 4 Jul 2010 07:54:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 4 Jul 2010 07:54:56 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Intellectual Property Rights statement on draft-ietf-ipsecme-ipsec-ha X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 14:55:00 -0000 Greetings again. As you probably saw earlier on the list, there is now an IPR statement filed on draft-ietf-ipsecme-ipsec-ha; please see . Having looked at the cited patent, the WG chairs do not see why this IPR statement should prevent the document from moving forwards as-is. Also, the IPR statement should not impede work on HA solution proposals. For general information about how the IETF handles IPR, please see . From paul.hoffman@vpnc.org Wed Jul 7 10:03:36 2010 Return-Path: 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 EC1A43A63EC for ; Wed, 7 Jul 2010 10:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 HKaWwfIisG86 for ; Wed, 7 Jul 2010 10:03:35 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id ECFB73A679F for ; Wed, 7 Jul 2010 10:03:34 -0700 (PDT) Received: from [10.20.30.158] ([75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o67H3F5P072101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Jul 2010 10:03:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 7 Jul 2010 10:02:59 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 17:03:36 -0000 [[ This topic generated a fair amount of discussion in the past; are folks still interested? ]] Greetings again. The WG has one item on our charter that we have barely discussed, namely failure detection. The charter item says that the work item is: >- A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at , and the following is directly derived from them. The basic problem being covered by the new extension is: - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes - Alice keeps sending ESP to Bob - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications - Alice starts sending IKE liveness checks until she is "sure" that the INVALID_SPI responses are not a DoS attack; this could be "several minutes" - Then Alice rekeys Some other problem cases include: - Bob has two gateways in some failover architecture. One gateway goes down, the other gateway detects this and wants to tell Alice to rekey - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system wants to tell Alice to rekey - Protocol robustness: Bob's gateway loses the SA without going down Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probably want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use "rekey" to mean "rekey or, if appropriate, resume". The proposed extension does not include the actual rekeying, just the context for them to do it now. The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. In QCD (), Bob gives Alice a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob must remember his tokens across reboots, or derive tokens from a master token that he memorizes across reboots, and Alice must remember the token (or a hash of it) for each SA. In SIR (), Alice sends a new Check_SPI query with a stateless cookie, essentially asking "do you really not know about this SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: - Support for different scenarios (load balancers, active clusters, failover) - Security from man-in-the-middle DoS attacks - Resources used - Intellectual property rights So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Wed Jul 7 12:03:20 2010 Return-Path: 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 650CD3A68FD for ; Wed, 7 Jul 2010 12:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 G1DXYCA1q6lJ for ; Wed, 7 Jul 2010 12:03:19 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id EBEEE3A6903 for ; Wed, 7 Jul 2010 12:02:48 -0700 (PDT) X-CheckPoint: {4C34DBF8-2-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o67J2pDq005217; Wed, 7 Jul 2010 22:02:51 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 7 Jul 2010 22:03:22 +0300 From: Yoav Nir To: Paul Hoffman Date: Wed, 7 Jul 2010 22:02:49 +0300 Thread-Topic: [IPsec] NUDGE: Starting discussion of failure detection proposals Thread-Index: AcseBxG6yiFSnJ2GRZK6puy9Dh2GZw== Message-ID: <9EF12848-9EA3-4024-8412-E9EB51D5BFA7@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] NUDGE: Starting discussion of failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:03:20 -0000 Sure we are, but I didn't want to start the discussion, because QCD is my p= roposal. Hopefully we've learned something from the history of XAuth vs Hybrid, and = we won't end up with two non-interoperable, proprietary ways of doing this,= neither of which makes it to RFC. I think that failure led to the rise of= L2TP client and maybe even the SSL VPN client. On Jul 7, 2010, at 8:02 PM, Paul Hoffman wrote: > [[ This topic generated a fair amount of discussion in the past; are folk= s still interested? ]] >=20 > Greetings again. The WG has one item on our charter that we have barely d= iscussed, namely failure detection. The charter item says that the work ite= m is: >=20 >> - A standards-track IKEv2 extension that allows an IKE peer to quickly a= nd securely detect that its opposite peer, while currently reachable, has l= ost its IKEv2/IPsec state. Changes to how the peers recover from this situa= tion are beyond the scope of this work item, as is improving the detection = of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-d= etienne-ikev2-recovery-03 can be used as starting points. >=20 > I gave a brief presentation on failure detection at the last IETF meeting= in Anaheim. The slides are at , and the following is directly derived from them. >=20 > The basic problem being covered by the new extension is: > - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob cra= shes > - Alice keeps sending ESP to Bob > - When Bob finally comes back up, he replies to Alice's ESP with INVALID= _SPI notifications > - Alice starts sending IKE liveness checks until she is "sure" that the = INVALID_SPI responses are not a DoS attack; this could be "several minutes" > - Then Alice rekeys >=20 > Some other problem cases include: > - Bob has two gateways in some failover architecture. One gateway goes d= own, the other gateway detects this and wants to tell Alice to rekey > - Bob has a bunch of gateways in some load-balancing or cluster architec= ture. One gateway is taken down on purpose, and the system wants to tell Al= ice to rekey > - Protocol robustness: Bob's gateway loses the SA without going down >=20 > Our primary goal is that, as soon as Bob starts sending INVALID_SPI respo= nses to Alice's ESP traffic, Bob and Alice should be able to quickly determ= ine that this is not an attack and therefore they probably want to rekey ri= ght away. Note that if Bob and Alice are also using session resumption, the= y can use that instead of rekeying; however, in the discussion here, we alw= ays use "rekey" to mean "rekey or, if appropriate, resume". The proposed ex= tension does not include the actual rekeying, just the context for them to = do it now. >=20 > The WG has seen two proposed solutions, QCD and SIR. The following are br= ief summaries of the two proposals. >=20 > In QCD (), Bob gives Alice = a secret token in the AUTH exchange, and then puts the token in his INVALID= _SPI response as a way to say "this SPI is gone". Bob must remember his tok= ens across reboots, or derive tokens from a master token that he memorizes = across reboots, and Alice must remember the token (or a hash of it) for eac= h SA. >=20 > In SIR (), Alic= e sends a new Check_SPI query with a stateless cookie, essentially asking "= do you really not know about this > SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing i= s stored on either side, so a man-in-the-middle can attack this to cause an= unnecessary rekey just as they can normal IKE. >=20 > The first task for the WG is to decide which of these two quite different= approaches to take. After we have done that, we can then hone the chosen p= roposal. During earlier discussion of the proposals, the following criteria= were mentioned as ones that the WG should consider when thinking about the= approaches: >=20 > - Support for different scenarios (load balancers, active clusters, fail= over) > - Security from man-in-the-middle DoS attacks > - Resources used > - Intellectual property rights >=20 > So: please start discussing the two proposals with respect to these crite= ria or other criteria that are important to you. In a few weeks (hopefully = well before the Maastricht meeting), I make a call for consensus and see wh= ere it leads us. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From turners@ieca.com Thu Jul 8 06:25:51 2010 Return-Path: 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 514C43A6AC1 for ; Thu, 8 Jul 2010 06:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 GUsBz+S3fDUV for ; Thu, 8 Jul 2010 06:25:49 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id B52C33A6ABF for ; Thu, 8 Jul 2010 06:25:49 -0700 (PDT) Received: (qmail 93627 invoked from network); 8 Jul 2010 13:25:48 -0000 Received: from thunderfish.local (turners@96.231.124.229 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 08 Jul 2010 06:25:47 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: dSaSuGQVM1nMPGF9Jqbsvf_y12A_16yaZk6BmXGd436lGiP c7JzNfiIFa30vKX7d6CQ0_iuoejV3eeIHWIye6tVFqnf9ZsCUg9QMagnhMDS Z7ViCmMQItfkqH9fQkuXEC3G2zKLzR3Mlxbs_XBxpHwqRI5I5sH3386J_u9o TYS8nm2Lft6XjKr9GhUgJemMHFimLGKUvEgGu6VHcgpU8qpwkbeNL4.qylFi DBd3kRr24t9VRZgvf0gSdj9sqbixgkyabHtOu1joLwSj04RyZzuRMnP8rYYI WlKpodfEptqrTvY0kis5j98HEX.nq2IxER5C9YRr41jO9HQGaAowfMg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C35D1DB.1070308@ieca.com> Date: Thu, 08 Jul 2010 09:25:47 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: IPsecme WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Intellectual Property Rights statement on draft-ietf-ipsecme-ipsec-ha X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 13:25:51 -0000 We'll be discussing this I-D on the July 15th telechat. spt Paul Hoffman wrote: > Greetings again. As you probably saw earlier on the list, there is now an IPR statement filed on draft-ietf-ipsecme-ipsec-ha; please see . Having looked at the cited patent, the WG chairs do not see why this IPR statement should prevent the document from moving forwards as-is. Also, the IPR statement should not impede work on HA solution proposals. > > For general information about how the IETF handles IPR, please see . > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From paul.hoffman@vpnc.org Fri Jul 9 08:47:53 2010 Return-Path: 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 111973A6A2F for ; Fri, 9 Jul 2010 08:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=1.259, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 mtWHhqIXkLVC for ; Fri, 9 Jul 2010 08:47:49 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 496A13A680F for ; Fri, 9 Jul 2010 08:47:49 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o69FlqRH051325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jul 2010 08:47:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 9 Jul 2010 08:47:35 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Fwd: Last Call: draft-ietf-msec-ipsec-group-counter-modes (Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 15:47:53 -0000 Of interest to this WG: >The IESG has received a request from the Multicast Security WG (msec) to >consider the following document: > >- 'Using Counter Modes with Encapsulating Security Payload (ESP) and > Authentication Header (AH) to Protect Group Traffic ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2010-07-23. Exceptionally, >comments may be sent to iesg@ietf.org instead. In either case, please >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-group-counter-modes-05.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15718&rfc_flag=0 --Paul Hoffman, Director --VPN Consortium From kagarigi@cisco.com Sat Jul 10 22:54:43 2010 Return-Path: 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 7874728B23E for ; Sat, 10 Jul 2010 22:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] 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 uUABBRgMEPrH for ; Sat, 10 Jul 2010 22:54:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D94E528C0DB for ; Sat, 10 Jul 2010 22:54:32 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM75OExAaHte/2dsb2JhbACgTXGkM5kuhScEg3mHAQ X-IronPort-AV: E=Sophos;i="4.55,182,1278288000"; d="scan'208";a="224662173" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 11 Jul 2010 05:54:10 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6B5s9HU027452 for ; Sun, 11 Jul 2010 05:54:10 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 11:24:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Jul 2010 11:24:06 +0530 Message-ID: <04BD913C7AD1B84297D26D5614FBE133BD52C5@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: latest message Id draft Thread-Index: AcsffiOAXHXQ7kOQR5erKqPKoyYrEgBPtrog References: From: "Kalyani Garigipati (kagarigi)" To: "IPsecme WG" X-OriginalArrivalTime: 11 Jul 2010 05:54:09.0879 (UTC) FILETIME=[7B3E7670:01CB20BD] Subject: [IPsec] latest message Id draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 05:54:43 -0000 Hi , Please find the latest message id draft in the following link. http://www.ietf.org/staging/draft-kagarigi-ipsecme-ikev2-windowsync-03.t xt regards, Kalyani From yumao9@gmail.com Sun Jul 11 03:06:34 2010 Return-Path: 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 C864D3A6842 for ; Sun, 11 Jul 2010 03:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6] 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 Kqy8P084g0IJ for ; Sun, 11 Jul 2010 03:06:33 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EECA43A6767 for ; Sun, 11 Jul 2010 03:06:32 -0700 (PDT) Received: by qwe5 with SMTP id 5so1142673qwe.31 for ; Sun, 11 Jul 2010 03:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=dSN5uEdIZb7eei1NWrOjdnf1o3aSHuYofXlTr5wqCe8=; b=qO22fzp14U4bL6MtVq3K06MN3dyl9yf1gOEztnEJQSM8WbjJ3it4HFD0pY352IGgG3 lTZlIOZnDMYXFKvTvoezBdldfCzHfvmPDd8F5BRjYDOHQrs7+7FavElXBPD3jONBAVbg J/JCqjBxDP6g531+UEoND8ZdRg4KOpMHK3Rng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=j36xg5lEB9cX8ysyJxOn+NjIY48LVLhQ4ZIU8rexuZ00w2iVAalxgJosQuf2j1urDF /gs4U5mc88lt6UYoHaw3q7EIt4v9iTn931DOgI1HiOibGOvqrVTtWSOjGx8zLZp1y2xz 7nSYWeqCIFppnptwZVb4v8DSQo+BRMN5DRd0o= MIME-Version: 1.0 Received: by 10.229.183.210 with SMTP id ch18mr7423167qcb.55.1278842796170; Sun, 11 Jul 2010 03:06:36 -0700 (PDT) Received: by 10.229.78.98 with HTTP; Sun, 11 Jul 2010 03:06:35 -0700 (PDT) Date: Sun, 11 Jul 2010 18:06:35 +0800 Message-ID: From: Toby Mao To: IPsecme WG Content-Type: multipart/alternative; boundary=0016e65bba7296df4e048b19ca25 Cc: maoyu@h3c.com Subject: [IPsec] DPD in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 10:06:35 -0000 --0016e65bba7296df4e048b19ca25 Content-Type: text/plain; charset=ISO-8859-1 Hi all: DPD(RFC 3706) provide a mechanism to detect dead IKEv1 peer. In draft-ietf-ipsecme-roadmap-07, 4.2.3.1, it tell us "This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers to this feature as a "liveness check" or "liveness test"." So we can learn DPD can be used in IKEv2. However, some issues need to discuss when used in IKEv2. #1: Sequence Number in DPD Message In rfc3706, sequence number in DPD message can prove liveliness and guard against message replay attack, it is presented in the notification data field in the Notify Payload format. However, Message ID in the IKEv2 can provide the same function(see WG draft draft-ietf-ipsecme-ikev2bis2.2). If DPD is used in IKEv2, DPD notify message can use Message ID in the IKEv2 message header other than define the other redundancy sequence number in the notification data field. Furthermore, another WG draft draft-ietf-ipsecme-ipsec-ha define SADB information to be synchronized in the clusters. If DPD use its unique sequence number , the number should also be synched as IKE SA counters. #2: Message Type RFC3706 define DPD Message as below: Notify Message Value R-U-THERE 36136 R-U-THERE-ACK 36137 But I do not see these definition in draft-ietf-ipsecme-ikev2bis or http://www.iana.org/assignments/ikev2-parameters. So, should we udpate RFC 3706 or make a detailed description in draft-ietf-ipsecme-ikev2bis ? --0016e65bba7296df4e048b19ca25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all:
=A0=A0=A0=A0=A0=A0=A0=A0 DPD(RFC 3706) provide a mechanism to de= tect dead IKEv1 peer.=A0 In=A0 draft-ietf-ipsecme-roadmap-0= 7, 4.2.3.1, it tell us "This RFC defines an optional extension to = IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers= to this feature as a "liveness check" or "liveness test&quo= t;."=A0 So we can learn DPD can be used in IKEv2. However,=A0 some iss= ues need to discuss when used in IKEv2.
=A0 =A0 =A0 =A0
=A0=A0=A0=A0=A0=A0=A0=A0 #1:=A0 Sequence Number in DPD = Message
=A0 =A0 =A0 =A0 In rfc3706, sequence number in DPD message can p= rove liveliness and guard against message replay attack, it is presented in= the notification data field in the Notify Payload format. However, Message= ID in the IKEv2 can provide the same function(see WG draft draft-ietf-ipsecme-ikev2bis 2.2). If DPD is used in IKEv2, DPD notify= message can use Message ID in the IKEv2 message header other than define t= he other redundancy sequence number in the notification data field. Further= more,=A0 another WG draft=A0 draft-ietf-ipsecme-ipsec-ha=A0 define SADB information to be synchronized in the clusters. If DPD us= e its unique sequence number , the number should also be synched as IKE SA = counters.

=A0=A0=A0=A0=A0=A0=A0=A0 #2:=A0=A0 Message Type
=A0=A0=A0=A0=A0 RFC3= 706 define DPD=A0 Message=A0 as below:
     Notify                 =
         Message Value
      R-U-THERE                   36136
      =
R-U-THERE-ACK           36137



      But I do not see these definition in draft-ietf-=
ipsecme-ikev2bis or http://www.iana.org/assignments/ikev2-parameter=
s.



   So,  should we udpate RFC 3706 or make a detailed description in draft-ietf-ipsecme-ikev2bis?

=20 --0016e65bba7296df4e048b19ca25-- From ynir@checkpoint.com Sun Jul 11 03:26:46 2010 Return-Path: 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 EADD93A699A for ; Sun, 11 Jul 2010 03:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6] 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 1bJ2IgL0wRRH for ; Sun, 11 Jul 2010 03:26:41 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id B58E53A698E for ; Sun, 11 Jul 2010 03:26:40 -0700 (PDT) X-CheckPoint: {4C39A8DB-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6BAQaDq022648; Sun, 11 Jul 2010 13:26:36 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 11 Jul 2010 13:27:08 +0300 From: Yoav Nir To: "'Toby Mao'" , IPsecme WG Date: Sun, 11 Jul 2010 13:27:08 +0300 Thread-Topic: [IPsec] DPD in IKEv2 Thread-Index: Acsg4NvCOFHCFE6xRWa/jbrpsXXkKQAAaRsw Message-ID: <006FEB08D9C6444AB014105C9AEB133FFE28C51DE8@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_006FEB08D9C6444AB014105C9AEB133FFE28C51DE8ilex01adcheck_" MIME-Version: 1.0 Cc: "maoyu@h3c.com" Subject: Re: [IPsec] DPD in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 10:26:47 -0000 --_000_006FEB08D9C6444AB014105C9AEB133FFE28C51DE8ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. Liveness check in IKEv2 is very much like any other INFORMATIONAL exchange.= Here's what the introduction says about this. An INFORMATIONAL request with no payloads (other than the empty Encrypted payload required by the syntax) is commonly used as a check for liveness. So you don't need any payloads, and no counters other than the message coun= ter in the IKE header. Also, you are correct that the counter gets synchron= ized to cluster members, just like following any other IKE message. Hope this helps Yoav ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of T= oby Mao Sent: Sunday, July 11, 2010 1:07 PM To: IPsecme WG Cc: maoyu@h3c.com Subject: [IPsec] DPD in IKEv2 Hi all: DPD(RFC 3706) provide a mechanism to detect dead IKEv1 peer. In = draft-ietf-ipsecme-roadmap-07, 4.2.3.1, it tell us "This RFC defines an optional extens= ion to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which= refers to this feature as a "liveness check" or "liveness test"." So we c= an learn DPD can be used in IKEv2. However, some issues need to discuss wh= en used in IKEv2. #1: Sequence Number in DPD Message In rfc3706, sequence number in DPD message can prove liveliness and= guard against message replay attack, it is presented in the notification d= ata field in the Notify Payload format. However, Message ID in the IKEv2 ca= n provide the same function(see WG draft draft-ietf-ipsecme-ikev2bis 2.2). If DPD is us= ed in IKEv2, DPD notify message can use Message ID in the IKEv2 message hea= der other than define the other redundancy sequence number in the notificat= ion data field. Furthermore, another WG draft draft-ietf-ipsecme-ipsec-ha= define SAD= B information to be synchronized in the clusters. If DPD use its unique seq= uence number , the number should also be synched as IKE SA counters. #2: Message Type RFC3706 define DPD Message as below: Notify Message Value R-U-THERE 36136 R-U-THERE-ACK 36137 But I do not see these definition in draft-ietf-ipsecme-ikev2bis or http://www.ia= na.org/assignments/ikev2-parameters. So, should we udpate RFC 3706 or make a detailed description in draft-i= etf-ipsecme-ikev2bis? --_000_006FEB08D9C6444AB014105C9AEB133FFE28C51DE8ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi.

 

Liveness check in IKEv2 is very much l= ike any other INFORMATIONAL exchange. Here’s what the introduction says a= bout this.

 

    &nb= sp;         An INFORMATIONAL request with no payloads (other than the

   empty Enc= rypted payload required by the syntax) is commonly used as a

   check for= liveness.

 

So you don’t need any payloads, = and no counters other than the message counter in the IKE header. Also, you are correct that the counter gets synchronized to cluster members, just like following any other IKE message.

 

Hope this helps

 

Yoav

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Toby Mao
Sent: Sunday, July 11, 2010 = 1:07 PM
To: IPsecme WG
Cc: maoyu@h3c.com
Subject: [IPsec] DPD in IKEv= 2

 

Hi all:
         DPD(RFC 3706) provide a mechanism to detect dead IKEv1 peer.  In  draft-ietf-ipsecme-roadmap-07, 4.2.3.1, it tell us &q= uot;This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers to this feature as a "liveness check" or "liveness test"."  So we can learn DPD c= an be used in IKEv2. However,  some issues need to discuss when used in IKEv2.
       
         #1:  Sequence Number = in DPD Message
        In rfc3706, sequence number in DPD message can prove liveliness and guard against message replay attack, it is presented i= n the notification data field in the Notify Payload format. However, Message = ID in the IKEv2 can provide the same function(see WG draft draft-ietf-ipsecme-ikev2bis 2.2). If DPD is used in I= KEv2, DPD notify message can use Message ID in the IKEv2 message header other tha= n define the other redundancy sequence number in the notification data field. Furthermore,  another WG draft  draft-ietf-ipsecme-ipsec-ha  define SADB informa= tion to be synchronized in the clusters. If DPD use its unique sequence number ,= the number should also be synched as IKE SA counters.

         #2:   Message Ty= pe
      RFC3706 define DPD  Message  as be= low:

&=
nbsp;    Notify       &nb=
sp;            =
      Message Value

      R-U-THERE      =
;             3=
6136

      R-U-THERE-ACK     &=
nbsp;     36137




 


      But I do not see these definition in draft-ietf-ipsecme-ikev2bis or http://www.iana.org/assignments/ikev2-parameters.




 


   So,  should we udpate RFC 3706 or make a detailed descrip=
tion in draft-ietf-ipsecme-ikev2bis?=

 

--_000_006FEB08D9C6444AB014105C9AEB133FFE28C51DE8ilex01adcheck_-- From rsjenwar@gmail.com Sun Jul 11 04:09:43 2010 Return-Path: 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 386F33A68E9 for ; Sun, 11 Jul 2010 04:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yVbvdXzK6fNO for ; Sun, 11 Jul 2010 04:09:42 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E8D5C3A6897 for ; Sun, 11 Jul 2010 04:09:41 -0700 (PDT) Received: by qyk2 with SMTP id 2so4051026qyk.10 for ; Sun, 11 Jul 2010 04:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=bu33lF3MBSmDo5QZwGWjvmz0blwkoepYAnGSdM04CBU=; b=gRG7KGvdOoBpaRE2WMwSdz5HIjtwcCCIBP3fEMI8g4Z4eE2KvoIOASglbTBQJnPxKS +m8UoAduXdXKuOqA46wsRoZALmVfH8q2H4fqYhdW8bxC0fMUUUhlCvouSkEHsA+XeVnO BtbM4L/nsLOXtfD33Bh5gXQyupMExDBLBkG0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XXSOARwiGxlaFXgJ1SIH2S0e0Wud24y36vloFBIxj5j3LJasvqNM8bxipXzbicTKLG Ric94k9uzdPt6IvOKJtEtGZ0ZolPuvDlBLOS+TxkllZkqXWuybITTZZRc0gusVL/cMDH DR0IvUFy0nT66HicziD8aIKRUu8mmzvBkMx/E= MIME-Version: 1.0 Received: by 10.224.40.137 with SMTP id k9mr6914414qae.388.1278846585792; Sun, 11 Jul 2010 04:09:45 -0700 (PDT) Received: by 10.229.91.144 with HTTP; Sun, 11 Jul 2010 04:09:45 -0700 (PDT) In-Reply-To: <4C1B1185.9090800@gmail.com> References: <4C1B1185.9090800@gmail.com> Date: Sun, 11 Jul 2010 16:39:45 +0530 Message-ID: From: Raj Singh To: IPsecme WG Content-Type: multipart/alternative; boundary=000feaf109ab77ea49048b1aaccd Subject: Re: [IPsec] HA design team started X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 11:09:43 -0000 --000feaf109ab77ea49048b1aaccd Content-Type: text/plain; charset=UTF-8 Hi Group, We would like to present the HA design team's output for IPsec Cluster Solution Draft before Maastricht meeting as http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt This draft solves the main issues of IPsec Cluster Problem Statement draft using a simple IKEv2 protocol extension, and provides implementation advice for other issues. I sincerely thanks all the team members of HA Design Team for attending all internal meetings and giving their valuable inputs and doing reviews. My special thanks to Yaron and Yoav for their expert inputs and comments. I would also like to thanks Paul for providing TeamSpeak server for conducting internal design team meetings. The team started with these draft as inputs. 1. http://tools.ietf.org/html/draft-kagarigi-ipsecme-ikev2-windowsync-00 - G. Kalyani 2. http://www.ietf.org/id/draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txtJ. Arora 3. http://www.ietf.org/id/draft-ietf-ipsecme-ipsec-ha-09.txt - Y. Nir - As Input The current draft is based on [1], then it got enhanced and extended with all team's contribution. The problem and solution presented in [2], is more towards load balancing than HA cluster. Also this problem can be solved using IKEv2 REDIRECT mechanism. Also, this solution requires IKEv2 protocol change. So, this is deferred for now. I request the IPsecME group members to review and give comments on http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt, so that we can discuss this draft with more details in Maastricht meeting. Regards, Raj Singh On Fri, Jun 18, 2010 at 11:56 AM, Yaron Sheffer wrote: > Hi, > > As promised, we have started a design team on IPsec HA. Paul and I have > asked Raj Singh to lead the team. His job is to make sure that the team > meets regularly in the next few weeks, and produces a good output document > before the Maastricht face-to-face meeting. > > The initial membership of the team is: > > - Raj Singh (rsjenwar@gmail.com, lead) > > - Jitender Arora (JArora@acmepacket.com) > - Min Huang (huangmin@huaweisymantec.com) > - Dacheng Zhang (zhangdacheng@huawei.com) > - Yoav Nir (ynir@checkpoint.com) > - Yaron Sheffer (yaronf.ietf@gmail.com, observer) > > According to IETF rules (see > http://www.ietf.org/iesg/statement/design-team.htm), every design team > needs to have a mission statement. So here it is: > > Produce a high-level solution document that covers most or all of the > issues raised by the HA problem statement (draft-ietf-ipsecme-ipsec-ha). Any > solution should be applicable to different deployments, in order to > accommodate the variety of existing and future IPsec products. Solutions > should have a similar level of security as the IKE/IPsec suite. > > Another process reminder: the design team's output serves as input to the > full WG, essentially like an individual draft. So all protocol decisions > will eventually be made by the working group. > > Thanks, > Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000feaf109ab77ea49048b1aaccd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Group,

We would like to present the HA design team's output for IPsec= Cluster Solution Draft before Maastricht meeting as http://tools.= ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt

This draft solves the main issues of IPsec Cluster Problem Statement dr= aft using a simple IKEv2 protocol extension, and=C2=A0 provides implement= ation advice for other issues.

I sincerely thanks all the team membe= rs of HA Design Team for attending all internal meetings and giving their v= aluable inputs and doing reviews.
My special thanks to Yaron and Yoav for their expert inputs and comments. I= would also like to thanks Paul for providing TeamSpeak server for conducti= ng internal design team meetings.

The team started with these draft = as inputs.
1. http://tools.ietf.org/html/draft-kagarigi-ipsec= me-ikev2-windowsync-00 - G. Kalyani
2. http://www.ietf.org/id/draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00= .txt J. Arora
3. ht= tp://www.ietf.org/id/draft-ietf-ipsecme-ipsec-ha-09.txt - Y. Nir - As I= nput

The current draft is based on [1], then it got enhanced and ext= ended with all team's contribution.
The problem and solution presented in [2], is more towards load balancing t= han HA cluster.
Also this problem can be solved using IKEv2 REDIRECT mec= hanism. Also, this solution requires IKEv2
protocol change. So, this is = deferred for now.

I request the IPsecME group members to review and give comments on http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.tx= t, so that we can discuss this draft with more details in Maastricht me= eting.

Regards,
Raj Singh
=C2=A0
On Fri, Jun 18, 2010 at 11:56 AM, Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:
Hi,

As pro= mised, we have started a design team on IPsec HA. Paul and I have asked Raj= Singh to lead the team. His job is to make sure that the team meets regula= rly in the next few weeks, and produces a good output document before the M= aastricht face-to-face meeting.

The initial membership of the team is:

- Raj Singh (rsjenwar@gmail.com, lead)= =20

- Jitender Arora (JArora@acmepacket.com)
- Min Huang (huangmin@huaweisymantec.= com)
- Dacheng Zhang (zhangdacheng@huawei.com)
- Yoav Nir (ynir@checkpoint.com)
- Yaron Sheffer (<= a href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail= .com, observer)

According to IETF rules (see http://www.ietf.org/iesg/statement/d= esign-team.htm), every design team needs to have a mission statement. S= o here it is:

Produce a high-level solution document that covers most or all of the i= ssues raised by the HA problem statement (draft-ietf-ipsecme-ipsec-ha). Any= solution should be applicable to different deployments, in order to accomm= odate the variety of existing and future IPsec products. Solutions should h= ave a similar level of security as the IKE/IPsec suite.

Another process reminder: the design team's output serves as input = to the full WG, essentially like an individual draft. So all protocol decis= ions will eventually be made by the working group.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron=20

_______________________________________________
IPsec mailing l= ist
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--000feaf109ab77ea49048b1aaccd-- From seokung@gmail.com Sat Jul 10 10:00:20 2010 Return-Path: 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 6709F3A68A7 for ; Sat, 10 Jul 2010 10:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GFG8NyQIIrmX for ; Sat, 10 Jul 2010 10:00:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7AA483A6850 for ; Sat, 10 Jul 2010 10:00:19 -0700 (PDT) Received: by iwn38 with SMTP id 38so3434052iwn.31 for ; Sat, 10 Jul 2010 10:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ZbTmEIrhSgDYXecBLZH07NhjfpFTgrG7jYmRFT0ltgU=; b=LjkKnOZyola8L2G8a0mePo2Wfi5CIx6+DeRxri7khRqgXvVRfyKX8wwrwGmXQIW8jq k+9HEUH1znoQnIWfgt6LKmW+dMWLjnmVF64xX9VJCGHZ0Maw64oBKduls6TId1bj43Cq o6dnTOWLWu0K8MqwPr94WBvNS1ItDJcvUj9w4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=r67hLClx+SePe+d0v/NUpN1PtU9cJ29fSI1Bn0yZpid7OwVJGkOgRW3VaOg40GhXYG 51qtjyRwJFsl4jQX6TD0HrBWToQUuol3/yH20PUwW7WiOl2YHdAopGTQligwABTDPwBV V3B871Sp4Uv2OuEYa/B2I6yiGDcih5fE+IYuM= MIME-Version: 1.0 Received: by 10.231.39.134 with SMTP id g6mr11778556ibe.8.1278781220918; Sat, 10 Jul 2010 10:00:20 -0700 (PDT) Received: by 10.231.30.139 with HTTP; Sat, 10 Jul 2010 10:00:20 -0700 (PDT) In-Reply-To: <1278186190527800.2.mail@mail> References: <1278186190527800.2.mail@mail> Date: Sun, 11 Jul 2010 02:00:20 +0900 Message-ID: From: Seokung Yoon To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=000325574a2e6b1795048b0b74a3 X-Mailman-Approved-At: Sun, 11 Jul 2010 08:05:48 -0700 Subject: [IPsec] Fwd: New Version Notification for draft-seokung-ipsecme-seed-ipsec-modes-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2010 17:00:20 -0000 --000325574a2e6b1795048b0b74a3 Content-Type: text/plain; charset=UTF-8 Dear all, I submitted a new draft regarding SEED-IPsec. This is for updating the existing RFC (RFC4196). Any comments would be appreciated. BR, Seokung ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: 2010/7/4 Subject: New Version Notification for draft-seokung-ipsecme-seed-ipsec-modes-00 To: seokung@kisa.or.kr Cc: yjkang@kisa.or.kr, rinyfeel@kisa.or.kr, hcjung@kisa.or.kr, jilee@kisa.or.kr A new version of I-D, draft-seokung-ipsecme-seed-ipsec-modes-00.txt has been successfully submitted by Seokung Yoon and posted to the IETF repository. Filename: draft-seokung-ipsecme-seed-ipsec-modes Revision: 00 Title: Modes of Operation for SEED for Use with IPsec Creation_date: 2010-07-04 WG ID: Independent Submission Number_of_pages: 7 Abstract: This document describes the use of the SEED block cipher algorithm in Counter (CTR) Mode, Counter with CBC-MAC (CCM) Mode and Galois/Counter Mode (GCM) as an IPsec Encapsulation Security Payload (ESP) mechanism to provide confidentiality and data origin authentication, and connectionless integrity. The IETF Secretariat. --000325574a2e6b1795048b0b74a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,
=C2=A0
I submitted a new draft regarding SEED-IPsec.
=C2=A0
This is for updating the existing RFC (RFC4196).
=C2=A0
Any comments would be appreciated.
=C2=A0
BR,
Seokung


=C2=A0
---------- Forwarded message ----------
From:= IETF I-D Submission Tool <idsubmission@ietf.org&g= t;
Date: 2010/7/4
Subject: New Version Notification for draft-seokung-ipsec= me-seed-ipsec-modes-00
To: seokung= @kisa.or.kr
Cc: yjkang@kisa.or.= kr, rinyfeel@kisa.or.kr, hcjung@kisa.or.kr, jilee@kisa.or.kr



A new version of I-D, draft-seokung-ipsecme-seed-ipsec-modes-00= .txt has been successfully submitted by Seokung Yoon and posted to the IETF= repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-seokung-ipse= cme-seed-ipsec-modes
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Modes of Operation for SEED for Use with IPsec
Creation_date:= =C2=A0 2010-07-04
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Independent= Submission
Number_of_pages: 7

Abstract:
This document describ= es the use of the SEED block cipher algorithm in
Counter (CTR) Mode, Counter with CBC-MAC (CCM) Mode and
Galois/Counter M= ode (GCM) as an IPsec Encapsulation Security Payload
(ESP) mechanism to = provide confidentiality and data origin
authentication, and connectionle= ss integrity.



The IETF Secretariat.




--000325574a2e6b1795048b0b74a3-- From yumao9@gmail.com Sun Jul 11 08:46:17 2010 Return-Path: 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 1FA603A69BB for ; Sun, 11 Jul 2010 08:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6] 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 PknePvHs5Y-x for ; Sun, 11 Jul 2010 08:46:15 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 4971C3A69B9 for ; Sun, 11 Jul 2010 08:46:15 -0700 (PDT) Received: by qwe5 with SMTP id 5so1212891qwe.31 for ; Sun, 11 Jul 2010 08:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Tk+pWWRp71GWgr3BsRpmfYljLNpX5ZFIH2igUdcRM0A=; b=XgxLOdR5joyVWRGLDzViv5A1yTpgwQ40aEDoX3Z+8/YVy+G7NbJLy2yq4o3XQZmDfg oPxYzgzSpyJ7n7V1D2f37MENWfJaDUJUB0WHMgHvI//PKQUvhS35bEmdU2nLeryPL0hc GINUzjN+pJzJ3v2TOZOWw8Y/9zdZxLWTNwzkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Kqoqfe3+Ya9V5PQKmauD/h34OajUnoKmF2plPlywqRm8uZ84sBLq7VSM/041Sdr897 otmFArJ9p7yPV5WMK9O9Ya5VFno6GSUlE3cspfjA1EQnQVY+bEsfx8f9XeJndE65vpTI dGzPIC4nqm0UD0RROgopsuGQjq9oMwYO9a+5w= MIME-Version: 1.0 Received: by 10.224.54.131 with SMTP id q3mr7130205qag.183.1278863178793; Sun, 11 Jul 2010 08:46:18 -0700 (PDT) Received: by 10.229.78.98 with HTTP; Sun, 11 Jul 2010 08:46:18 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FFE28C51DE8@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133FFE28C51DE8@il-ex01.ad.checkpoint.com> Date: Sun, 11 Jul 2010 23:46:18 +0800 Message-ID: From: Toby Mao To: Yoav Nir Content-Type: multipart/alternative; boundary=0015175cf7b67d07a1048b1e8949 Cc: IPsecme WG , "maoyu@h3c.com" Subject: Re: [IPsec] DPD in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 15:46:17 -0000 --0015175cf7b67d07a1048b1e8949 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yoav: Thanks for your explanation. So, if we want to check liveliness, an Informational request message without payloads will be send and an Informational response message without payloads can prove the peer's liveliness. Best Toby On Sun, Jul 11, 2010 at 6:27 PM, Yoav Nir wrote: > Hi. > > > > Liveness check in IKEv2 is very much like any other INFORMATIONAL exchang= e. > Here=92s what the introduction says about this. > > > > An INFORMATIONAL request with no payloads (other than the > > empty Encrypted payload required by the syntax) is commonly used as a > > check for liveness. > > > > So you don=92t need any payloads, and no counters other than the message > counter in the IKE header. Also, you are correct that the counter gets > synchronized to cluster members, just like following any other IKE messag= e. > > > > Hope this helps > > > > Yoav > > > ------------------------------ > > *From:* ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On Behalf > Of *Toby Mao > *Sent:* Sunday, July 11, 2010 1:07 PM > *To:* IPsecme WG > *Cc:* maoyu@h3c.com > *Subject:* [IPsec] DPD in IKEv2 > > > > Hi all: > DPD(RFC 3706) provide a mechanism to detect dead IKEv1 peer. In= draft-ietf-ipsecme-roadmap-07, > 4.2.3.1, it tell us > "This RFC > defines an optional extension to IKEv1; dead peer detection (DPD) is an > integral part of IKEv2, which refers to this feature as a "liveness check= " > or "liveness test"." So we can learn DPD can be used in IKEv2. However, > some issues need to discuss when used in IKEv2. > > #1: Sequence Number in DPD Message > In rfc3706, sequence number in DPD message can prove liveliness a= nd > guard against message replay attack, it is presented in the notification > data field in the Notify Payload format. However, Message ID in the IKEv2 > can provide the same function(see WG draft draft-ietf-ipsecme-ikev2bis2.2). If DPD is= used in IKEv2, DPD notify message can use Message ID in the > IKEv2 message header other than define the other redundancy sequence numb= er > in the notification data field. Furthermore, another WG draft > draft-ietf-ipsecme-ipsec-ha > define SADB information to be synchronized in the clusters. If DPD use it= s > unique sequence number , the number should also be synched as IKE SA > counters. > > #2: Message Type > RFC3706 define DPD Message as below: > > Notify Message Value > > R-U-THERE 36136 > > R-U-THERE-ACK 36137 > > > > > > But I do not see these definition in draft-ietf-ipsecme-ikev2bis or http://www= .iana.org/assignments/ikev2-parameters. > > > > > > So, should we udpate RFC 3706 or make a detailed description in draft= -ietf-ipsecme-ikev2bis ? > > > --0015175cf7b67d07a1048b1e8949 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yoav:

=A0=A0=A0=A0=A0 Thanks for your explanation.
=A0=A0=A0= =A0=A0 So, if we want to check liveliness,=A0 an Informational request mess= age without payloads will be send and an Informational response message wit= hout payloads can prove the peer's liveliness.

Best
=A0 Toby


On Sun, Jul 11, = 2010 at 6:27 PM, Yoav Nir <ynir@checkpoint.com> wrote:

Hi.

=A0

Liveness check= in IKEv2 is very much like any other INFORMATIONAL exchange. Here=92s what the introduction says about this.

=A0

=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0An INFORMATIONAL request with no payloads (other than the

=A0=A0= empty Encrypted payload required by the syntax) is commonly used as a

=A0=A0= check for liveness.

=A0

So you don=92t= need any payloads, and no counters other than the message counter in the IKE header. Also, you are correct that the counter gets synchronized to cluster members, just like following any other IKE message.

=A0

Hope this help= s

=A0

Yoav

=A0

From: ipsec-bounces@i= etf.org [mailto:ipsec-bounces@ietf.org] On B= ehalf Of Toby Mao
Sent: Sunday, July 11, 201= 0 1:07 PM
To: IPsecme WG
Cc: maoyu@h3c.com
Subject: [IPsec] DPD in IK= Ev2

=A0

Hi all:
=A0=A0=A0=A0=A0=A0=A0=A0 DPD(RFC 3706) provide a mechanism to detect dead IKEv1 peer.=A0 In=A0 draft-ietf-ip= secme-roadmap-07, 4.2.3.1, it tell us "This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers to this feature as a "liveness check" or "liveness test"."=A0 So we can learn DPD can be used in IKEv2. However,=A0 some issues need to discuss when used in IKEv2.
=A0 =A0 =A0 =A0
=A0=A0=A0=A0=A0=A0=A0=A0 #1:=A0 Sequence Number in DPD Message
=A0 =A0 =A0 =A0 In rfc3706, sequence number in DPD message can prove liveliness and guard against message replay attack, it is presented i= n the notification data field in the Notify Payload format. However, Message = ID in the IKEv2 can provide the same function(see WG draft dr= aft-ietf-ipsecme-ikev2bis 2.2). If DPD is used in IKEv2, DPD notify message can use Message ID in the IKEv2 message header other tha= n define the other redundancy sequence number in the notification data field. Furthermore,=A0 another WG draft=A0 draft-ietf-ipsecme-ips= ec-ha=A0 define SADB information to be synchronized in the clusters. If DPD use its unique sequence number ,= the number should also be synched as IKE SA counters.

=A0=A0=A0=A0=A0=A0=A0=A0 #2:=A0=A0 Message Type
=A0=A0=A0=A0=A0 RFC3706 define DPD=A0 Message=A0 as below: 

=A0=A0=A0=A0 Notify=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 Message Value

=A0=A0=A0=A0=A0 R-U-THERE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 36136

=A0=A0=A0=A0=A0 R-U-THERE-ACK=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 36137




=A0


=A0=A0=A0=A0=A0 But I do not see these definition in draft=
-ietf-ipsecme-ikev2bis or http://www.iana.org/assignments/ikev2-par=
ameters.





=A0


=A0=A0 So,=A0 should we udpate RFC 3706 or make a detailed description in <=
a href=3D"http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2bis/" ta=
rget=3D"_blank">draft-ietf-ipsecme-ikev2bis?

=A0


--0015175cf7b67d07a1048b1e8949-- From sheila.frankel@nist.gov Sun Jul 11 17:56:49 2010 Return-Path: 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 352A328C10C for ; Sun, 11 Jul 2010 17:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] 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 mnxjgHNb0YBc for ; Sun, 11 Jul 2010 17:56:47 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 81DA728C10B for ; Sun, 11 Jul 2010 17:56:47 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6C0ujKo003858; Sun, 11 Jul 2010 20:56:45 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sun, 11 Jul 2010 20:56:23 -0400 From: "Frankel, Sheila E." To: Yaron Sheffer , IPsecme WG Date: Sun, 11 Jul 2010 20:56:23 -0400 Thread-Topic: [IPsec] Roadmap -07: two minor and one major comments Thread-Index: AcsVw33pvTIFeX/ZSECza0UkhuNfJwLmM252 Message-ID: References: <4C26F1F1.1080402@gmail.com> In-Reply-To: <4C26F1F1.1080402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Sean Turner , Paul Hoffman Subject: Re: [IPsec] Roadmap -07: two minor and one major comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 00:56:49 -0000 We just submitted version -08 of the Roadmap doc. As Yaron requested, we changed the reference in section 5.2.4 and eliminated Appendix A. We left RFC 4359 in the doc, since some (but not all) of the msec RFCs were deleted, but we felt this one should remain. (It's not one of the RFCs that Pasi wanted deleted.) Sheila and Suresh ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer [yaronf.ietf@gmail.com] Sent: Sunday, June 27, 2010 2:38 AM To: IPsecme WG Subject: [IPsec] Roadmap -07: two minor and one major comments 5.2.4: [draft-ietf-ipsecme-aes-ctr-ikev2] is used as a reference, instead of [ipsecme-2]. 6.5 (rfc 4359 on using RSA with ESP/AH): if all of msec goes away, I don't see a reason to leave this one in. There's absolutely no reason to implement it other than multicast. Also, per my comment to -06, I still think that Appendix A (req levels for RFCs that are *not* algorithms) needs to go: - It mostly consists of empty space, "optional" and "N/A". - It adds normative weight to an informative document. - It is of little use to implementers. People will be reading the roadmap doc itself to decide what RFCs they need in their product, based on market needs. Thanks, Yaron From root@core3.amsl.com Sun Jul 11 18:00:03 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8DCDE28C106; Sun, 11 Jul 2010 18:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712010002.8DCDE28C106@core3.amsl.com> Date: Sun, 11 Jul 2010 18:00:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-roadmap-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 01:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s) : S. Frankel, S. Krishnan Filename : draft-ietf-ipsecme-roadmap-08.txt Pages : 61 Date : 2010-07-11 Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-08.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-roadmap-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-11175002.I-D@ietf.org> --NextPart-- From david.black@emc.com Sun Jul 11 19:56:52 2010 Return-Path: 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 EE0033A6910; Sun, 11 Jul 2010 19:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 ITq7f8p83GSQ; Sun, 11 Jul 2010 19:56:52 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 019A93A690F; Sun, 11 Jul 2010 19:56:51 -0700 (PDT) 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.3.2/Switch-3.1.7) with ESMTP id o6C2ukss012596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jul 2010 22:56:47 -0400 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 11 Jul 2010 22:56:41 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o6C2udis016078; Sun, 11 Jul 2010 22:56:40 -0400 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 22:56:39 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Jul 2010 22:56:37 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-ipsecme-roadmap-08 Thread-Index: Acshbdh+rbRNBc1hT52qc/HpStEy/g== From: To: , , X-OriginalArrivalTime: 12 Jul 2010 02:56:39.0575 (UTC) FILETIME=[D994CA70:01CB216D] X-EMM-EM: Active Cc: ipsec@ietf.org, turners@ieca.com, paul.hoffman@vpnc.org, david.black@emc.com, yaronf@checkpoint.com Subject: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 02:56:53 -0000 I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq .=20 Please resolve these comments along with any other comments you may = receive. Summary: This draft is on the right track, but has open issues, described in the = review. This is a very useful summary of all of the RFCs (and some in-progress = Internet-Drafts) that specify or are related to IPsec. It will be very = useful to those new to IPsec, as it describes the organization of the = RFCs and relationships among them.=20 I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the = applicability of combined mode algorithms to IPsec-v2. All of the other = comments in this review are minor. Section 2.2 lists the RFC # range for IPsec-v1. Please also list the = RFC # ranges for IPsec-v2 and IPsec-v3. ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined = mode algorithms are "not a feature of IPsec-v2" and hence lists them as = N/A. That's not correct. The correct situation is: - Combined mode algorithms for ESP can be negotiated as encryption algorithms (the integrity protection algorithm would typically be omitted proposals that do this). - Combined mode algorithms cannot be used with IKEv1, as they're incompatible with its design (see the Introduction section of RFC 5282 for a more detailed explanation). Hence the N/A entries for IKEv1 are correct, but both AES-CCM and = AES-GCM should be "optional" for ESPv2 (and the NOTE should be revised = accordingly). Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC = 5116. Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If = that is correct, it should be stated. Section 8.8.1 also appears to be IPsec-v2 only, and in addition to = stating that should comment that this was not widely adopted, and NAT = traversal is the commonly used mechanism to deal with NATs. In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". If you want = to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC = 3821. idnits 2.12.04 found some minor nits: ** There are 4 instances of too long lines in the document, the = longest one being 3 characters in excess of 72. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From turners@ieca.com Mon Jul 12 06:49:08 2010 Return-Path: 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 391253A6783 for ; Mon, 12 Jul 2010 06:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 TnGNWFXVfe+t for ; Mon, 12 Jul 2010 06:49:07 -0700 (PDT) Received: from smtp115.biz.mail.mud.yahoo.com (smtp115.biz.mail.mud.yahoo.com [209.191.68.75]) by core3.amsl.com (Postfix) with SMTP id 2385B3A65A5 for ; Mon, 12 Jul 2010 06:49:07 -0700 (PDT) Received: (qmail 6096 invoked from network); 12 Jul 2010 13:49:04 -0000 Received: from thunderfish.local (turners@96.241.2.232 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 12 Jul 2010 06:49:03 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: _9F9I.QVM1nn21GCJIq65ILXe79eEvcOIckWWz2osb4TQo4 _0VoM8TNi1T3sGlWP2rKoH1xNCUEA1BeWlPu31q3C4i2XBPItHJr7dB86xhl Jrad7fBf0BUyseCOIYrqK_seFFePMfpot8VboLPIi01sjHVZ8jDpJXA.7nBe Meg6zs690fdLPW1xAcArSj8Zj33G5TvBXOwjKNgsoJvd8XyvS7zlm6nQx3zU l.fjqHru.QlUokUJ7RDjEpuXz2W6H3Xp.tPahOQ90EUAyOkXQboo1eXtmDCM KWJeHRHLWsiYX.e0u6xH1TlxUqEvmVBfHHYthW.nqRfgtDnEQdocWdg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C3B1D4C.9050909@ieca.com> Date: Mon, 12 Jul 2010 09:49:00 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Frankel, Sheila E." References: <4C26F1F1.1080402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Roadmap -07: two minor and one major comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 13:49:08 -0000 I placed it on the 2010-08-12 telechat. spt Frankel, Sheila E. wrote: > We just submitted version -08 of the Roadmap doc. As Yaron requested, we changed the reference in section 5.2.4 and eliminated Appendix A. We left RFC 4359 in the doc, since some (but not all) of the msec RFCs were deleted, but we felt this one should remain. (It's not one of the RFCs that Pasi wanted deleted.) > > Sheila and Suresh > ________________________________________ > From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer [yaronf.ietf@gmail.com] > Sent: Sunday, June 27, 2010 2:38 AM > To: IPsecme WG > Subject: [IPsec] Roadmap -07: two minor and one major comments > > 5.2.4: [draft-ietf-ipsecme-aes-ctr-ikev2] is used as a reference, > instead of [ipsecme-2]. > > 6.5 (rfc 4359 on using RSA with ESP/AH): if all of msec goes away, I > don't see a reason to leave this one in. There's absolutely no reason to > implement it other than multicast. > > Also, per my comment to -06, I still think that Appendix A (req levels > for RFCs that are *not* algorithms) needs to go: > > - It mostly consists of empty space, "optional" and "N/A". > - It adds normative weight to an informative document. > - It is of little use to implementers. People will be reading the > roadmap doc itself to decide what RFCs they need in their product, based > on market needs. > > Thanks, > Yaron > From yaronf.ietf@gmail.com Mon Jul 12 14:15:45 2010 Return-Path: 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 2F61B3A6C8B for ; Mon, 12 Jul 2010 14:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 lxrvGstZEuWV for ; Mon, 12 Jul 2010 14:15:35 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 792F03A6B87 for ; Mon, 12 Jul 2010 14:15:28 -0700 (PDT) Received: by wwi17 with SMTP id 17so377790wwi.13 for ; Mon, 12 Jul 2010 14:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=jU8eMksJQSphzhyvViRk7kkr4yTqAAbwRMeATuVVshg=; b=i3EhcRv6DL/CFY8m9f9SK5fMT6693y8yiqnNvmVRY80LMROviDC3okCrVFBXmgiHpk PzldEXs7Io9cCs7+7BgsoXf0jZ3mioE4YSfnMcEPmM+1EScz/WrN1jPhqJRKbBkrOi3T 83vQciC4thICSan3qalYALSF+0lqSl4hGNZL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=JfPhrB/6OKMJNvKPZL20Vq/9UfqciR20yoO70DmOAnlxW+vIo+58W6e8YyYWiBSXrl n9TAZpq9rV8SD4V/eYQkDcR4Cj0UVSjhRxcR2zA7K30/VNj+QMNQhOHIuFkkl0V8qLRE qgdQLIDYlpJLw7ki2x6nD9sWmB9mLiKygGHKY= Received: by 10.227.132.80 with SMTP id a16mr13192065wbt.170.1278969330349; Mon, 12 Jul 2010 14:15:30 -0700 (PDT) Received: from [10.0.0.1] ([109.67.45.226]) by mx.google.com with ESMTPS id a27sm33795307wbe.12.2010.07.12.14.15.28 (version=SSLv3 cipher=RC4-MD5); Mon, 12 Jul 2010 14:15:29 -0700 (PDT) Message-ID: <4C3B85EE.50809@gmail.com> Date: Tue, 13 Jul 2010 00:15:26 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: I-D Action:draft-kuegler-ipsecme-pace-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:15:45 -0000 Hi, following the group's decision to stop working on PAKE, we would like to progress this draft as an individual submission and publish it as Experimental. I expect other PAKE proposals to follow a similar path. Anyway, we believe the draft is now in reasonably good shape, and would appreciate comments off-list. Thanks, Yaron -------- Original Message -------- Subject: I-D Action:draft-kuegler-ipsecme-pace-ikev2-02.txt Date: Sun, 11 Jul 2010 12: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 : Password Authenticated Connection Establishment with IKEv2 Author(s) : D. Kuegler, Y. Sheffer Filename : draft-kuegler-ipsecme-pace-ikev2-02.txt Pages : 15 Date : 2010-07-11 IKEv2 does not allow secure peer authentication when using short credential strings, i.e. passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of PACE (Password Authenticated Connection Establishment) to the setting of IKEv2 and demonstrates the advantages of this integration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kuegler-ipsecme-pace-ikev2-02.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. From yaronf.ietf@gmail.com Tue Jul 13 04:46:49 2010 Return-Path: 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 6E8CC3A69C5 for ; Tue, 13 Jul 2010 04:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599] 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 r5D+dJlYIkXL for ; Tue, 13 Jul 2010 04:46:48 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0B2593A657C for ; Tue, 13 Jul 2010 04:46:47 -0700 (PDT) Received: by wwi17 with SMTP id 17so755196wwi.13 for ; Tue, 13 Jul 2010 04:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HIWBnBDTGqC/uQ1Dlz/AiVnT0h59GyjVNprswsAPVE8=; b=ZubnVI3keqLGn1y6a5ZqUVrmg5TGXbK1Q8nnv1TxQjSNygDQPYJLdqeHE5Kxo8CBSN H9gWnN3lmsamhR2BCXqRb7vVAQ1t0wHVaGxhLt/KxydJsAT/MlCqAyzrIJn0Ub3tr8l7 OH4L8m5vSpaL3Sjh06mAaw9zxMRfY8VlMbh8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=TMzD6v7JlD1nKwIJxhb68Xax6OfgRUxm4JyGUNrkP41OAdT9/SX6HHivd70f8VEgqO b7TXSXXSz0Pk2EG8SC88KD1zELbz6XM4ZgLNyMFR519sXNtZLDG1JaRJ4ImXyHG3sSIm SfTtOb/VIuV671N4gW4Au+fqM73c0tyc59a7w= Received: by 10.227.135.71 with SMTP id m7mr10665399wbt.11.1279021612655; Tue, 13 Jul 2010 04:46:52 -0700 (PDT) Received: from [10.0.0.1] (bzq-109-67-45-226.red.bezeqint.net [109.67.45.226]) by mx.google.com with ESMTPS id i25sm38920702wbi.10.2010.07.13.04.46.51 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Jul 2010 04:46:52 -0700 (PDT) Message-ID: <4C3C5229.4080606@gmail.com> Date: Tue, 13 Jul 2010 14:46:49 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Hoffman , IPsecme WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] NUDGE: Starting discussion of failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 11:46:49 -0000 Hi everyone, we intend to have a thorough discussion of failure detection in Maastricht. Please make sure to read the two drafts in advance of the WG meeting (which is Monday morning!) so we can get this thing going at last. Email comments *before* the meeting would be very useful, of course. Thanks, Yaron On 07/07/2010 08:02 PM, Paul Hoffman wrote: > [[ This topic generated a fair amount of discussion in the past; are folks still interested? ]] > > Greetings again. The WG has one item on our charter that we have barely discussed, namely failure detection. The charter item says that the work item is: > >> - A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. > > I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at, and the following is directly derived from them. > > The basic problem being covered by the new extension is: > - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes > - Alice keeps sending ESP to Bob > - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications > - Alice starts sending IKE liveness checks until she is "sure" that the INVALID_SPI responses are not a DoS attack; this could be "several minutes" > - Then Alice rekeys > > Some other problem cases include: > - Bob has two gateways in some failover architecture. One gateway goes down, the other gateway detects this and wants to tell Alice to rekey > - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system wants to tell Alice to rekey > - Protocol robustness: Bob's gateway loses the SA without going down > > Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probably want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use "rekey" to mean "rekey or, if appropriate, resume". The proposed extension does not include the actual rekeying, just the context for them to do it now. > > The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. > > In QCD (), Bob gives Alice a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob must remember his tokens across reboots, or derive tokens from a master token that he memorizes across reboots, and Alice must remember the token (or a hash of it) for each SA. > > In SIR (), Alice sends a new Check_SPI query with a stateless cookie, essentially asking "do you really not know about this > SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. > > The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: > > - Support for different scenarios (load balancers, active clusters, failover) > - Security from man-in-the-middle DoS attacks > - Resources used > - Intellectual property rights > > So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Tue Jul 13 07:40:22 2010 Return-Path: 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 228333A68DD for ; Tue, 13 Jul 2010 07:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 atfLzl6hdBfi for ; Tue, 13 Jul 2010 07:40:21 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 618E53A6899 for ; Tue, 13 Jul 2010 07:40:21 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6DEeSv9010193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jul 2010 07:40:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C3C5229.4080606@gmail.com> References: <4C3C5229.4080606@gmail.com> Date: Tue, 13 Jul 2010 07:40:27 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] NUDGE: Starting discussion of failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 14:40:22 -0000 FWIW, there is a broken link in my message. The two drafts under discussion are: QCD () SIR () --Paul Hoffman, Director --VPN Consortium From smb@cs.columbia.edu Wed Jul 14 11:54:18 2010 Return-Path: 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 77A353A6A97 for ; Wed, 14 Jul 2010 11:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 MCi+ozmQKKun for ; Wed, 14 Jul 2010 11:54:17 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 4CECC3A6A72 for ; Wed, 14 Jul 2010 11:54:17 -0700 (PDT) Received: from v230.vpn.iad.rg.net (v230.vpn.iad.rg.net [198.180.150.230]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id o6EIsOBF025008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Jul 2010 14:54:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <2B8448F5-4BE4-4A6B-A836-1FE95446774C@cs.columbia.edu> Date: Wed, 14 Jul 2010 14:54:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B8448F5-4BE4-4A6B-A836-1FE95446774C@cs.columbia.edu> To: Steven Bellovin X-Mailer: Apple Mail (2.1081) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: ipsec@ietf.org Subject: Re: [IPsec] Volunteers wanted for IPsec configuration experiment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:54:18 -0000 A tech report on our IPsec configuration system is at = http://mice.cs.columbia.edu/getTechreport.php?techreportID=3D1433 . We = hope to upload the code to Sourceforge shortly.= From paul.hoffman@vpnc.org Fri Jul 16 12:18:47 2010 Return-Path: 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 C37B63A6A74; Fri, 16 Jul 2010 12:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.411 X-Spam-Level: X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 MZWaE3iYktcd; Fri, 16 Jul 2010 12:18:46 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D3E613A67E3; Fri, 16 Jul 2010 12:18:46 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6GJIeH4069259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 12:18:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 16 Jul 2010 12:18:39 -0700 To: , , , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org, turners@ieca.com, david.black@emc.com, yaronf@checkpoint.com Subject: Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 19:18:47 -0000 At 10:56 PM -0400 7/11/10, wrote: >Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC # ranges for IPsec-v2 and IPsec-v3. Disagree. The definition of IPsec-v2 and -v3 is complicated, as is clear from the document. Listing RFCs here will send the wrong message. >** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode algorithms are "not a feature of IPsec-v2" and hence lists them as N/A. That's not correct. The correct situation is: >- Combined mode algorithms for ESP can be negotiated as encryption > algorithms (the integrity protection algorithm would typically > be omitted proposals that do this). >- Combined mode algorithms cannot be used with IKEv1, as they're > incompatible with its design (see the Introduction section of > RFC 5282 for a more detailed explanation). >Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM should be "optional" for ESPv2 (and the NOTE should be revised accordingly). I am having a hard time following your logic here. Where in "IPsec-v2" do you see combined modes as being defined? I agree that they can be negotiated for ESP; why does that make them a feature for all of IPsec-v2? >Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116. I think you meant this for 5.4.4. It is a reasonable addition. >Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If that is correct, it should be stated. Good catch, it should be stated. >Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating that should comment that this was not widely adopted, and NAT traversal is the commonly used mechanism to deal with NATs. RFC 2709 was only a model, not a protocol. The model and protocol are both part of IPsec-v3, but RFC 2709 was not "part of" IPsec-v2 in that it was suggestions for deployment. >In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". Agree. >If you want to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821. I don't those help here. >idnits 2.12.04 found some minor nits: > > ** There are 4 instances of too long lines in the document, the longest one > being 3 characters in excess of 72. These are non-visible gremlins; the RFC Production Center can squash them easily. --Paul Hoffman, Director --VPN Consortium From david.black@emc.com Sun Jul 18 16:30:59 2010 Return-Path: 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 32BC83A6800; Sun, 18 Jul 2010 16:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 2JASMc2ZD06L; Sun, 18 Jul 2010 16:30:55 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 56FBB3A69AD; Sun, 18 Jul 2010 16:30:51 -0700 (PDT) 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.3.2/Switch-3.1.7) with ESMTP id o6INUrBa006982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 19:30:53 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Sun, 18 Jul 2010 19:30:47 -0400 Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o6INUPmv026034; Sun, 18 Jul 2010 19:30:43 -0400 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Jul 2010 19:30:41 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Jul 2010 19:30:39 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08 Thread-Index: AcslG8VaRvQa/RARSxCEej1h6SRt1ABs5X9A References: From: To: , , , X-OriginalArrivalTime: 18 Jul 2010 23:30:41.0777 (UTC) FILETIME=[3CA6B610:01CB26D1] X-EMM-EM: Active Cc: ipsec@ietf.org, turners@ieca.com, david.black@emc.com, yaronf@checkpoint.com Subject: Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 23:30:59 -0000 Paul, > >Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC # ranges for IPsec-v2 and > IPsec-v3. >=20 > Disagree. The definition of IPsec-v2 and -v3 is complicated, as is clear from the document. Listing > RFCs here will send the wrong message. How about listing the RFC # for just the architecture RFCs (2401 for v2, 4301 for v3)? It seems odd/inconsistent to indicate in this section where in the RFC sequence one can find only the truly obsolete IPsec-v1. > >** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode algorithms are "not a > > feature of IPsec-v2" and hence lists them as N/A. That's not correct. The correct situation is: > >- Combined mode algorithms for ESP can be negotiated as encryption > > algorithms (the integrity protection algorithm would typically > > be omitted proposals that do this). > >- Combined mode algorithms cannot be used with IKEv1, as they're > > incompatible with its design (see the Introduction section of > > RFC 5282 for a more detailed explanation). > >Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM should be "optional" for > >ESPv2 (and the NOTE should be revised accordingly). >=20 > I am having a hard time following your logic here. Where in "IPsec-v2" do you see combined modes > as being defined? I agree that they can be negotiated for ESP; why does that make them a feature > for all of IPsec-v2? The current "not a feature of IPsec-v2" language will be (mis)read as "cannot be used with IPsec-v2." Since we agree that the latter implication is incorrect, the language should be edited to avoid creating that incorrect implication. [... snip ...] > >Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating that should comment that > this was not widely adopted, and NAT traversal is the commonly used mechanism to deal with NATs. >=20 > RFC 2709 was only a model, not a protocol. The model and protocol are both part of IPsec-v3, but RFC > 2709 was not "part of" IPsec-v2 in that it was suggestions for deployment. I suggest adding some form of the above two sentences to 8.8.1 for clarity. Thanks, --David > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Friday, July 16, 2010 3:19 PM > To: Black, David; gen-art@ietf.org; sheila.frankel@nist.gov; suresh.krishnan@ericsson.com > Cc: ipsec@ietf.org; turners@ieca.com; Black, David; yaronf@checkpoint.com > Subject: Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08 >=20 > At 10:56 PM -0400 7/11/10, wrote: > >Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC # ranges for IPsec-v2 and > IPsec-v3. >=20 > Disagree. The definition of IPsec-v2 and -v3 is complicated, as is clear from the document. Listing > RFCs here will send the wrong message. >=20 > >** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode algorithms are "not a > feature of IPsec-v2" and hence lists them as N/A. That's not correct. The correct situation is: > >- Combined mode algorithms for ESP can be negotiated as encryption > > algorithms (the integrity protection algorithm would typically > > be omitted proposals that do this). > >- Combined mode algorithms cannot be used with IKEv1, as they're > > incompatible with its design (see the Introduction section of > > RFC 5282 for a more detailed explanation). > >Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM should be "optional" for > ESPv2 (and the NOTE should be revised accordingly). >=20 > I am having a hard time following your logic here. Where in "IPsec-v2" do you see combined modes as > being defined? I agree that they can be negotiated for ESP; why does that make them a feature for all > of IPsec-v2? >=20 > >Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116. >=20 > I think you meant this for 5.4.4. It is a reasonable addition. >=20 > >Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If that is correct, it should be > stated. >=20 > Good catch, it should be stated. >=20 > >Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating that should comment that > this was not widely adopted, and NAT traversal is the commonly used mechanism to deal with NATs. >=20 > RFC 2709 was only a model, not a protocol. The model and protocol are both part of IPsec-v3, but RFC > 2709 was not "part of" IPsec-v2 in that it was suggestions for deployment. >=20 > >In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". >=20 > Agree. >=20 > >If you want to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821. >=20 > I don't those help here. >=20 > >idnits 2.12.04 found some minor nits: > > > > ** There are 4 instances of too long lines in the document, the longest one > > being 3 characters in excess of 72. >=20 > These are non-visible gremlins; the RFC Production Center can squash them easily. >=20 > --Paul Hoffman, Director > --VPN Consortium From ynir@checkpoint.com Mon Jul 19 01:35:21 2010 Return-Path: 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 5DDBA3A68E9 for ; Mon, 19 Jul 2010 01:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] 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 vMZVd4Oo4cv8 for ; Mon, 19 Jul 2010 01:35:20 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 718B33A687F for ; Mon, 19 Jul 2010 01:35:19 -0700 (PDT) X-CheckPoint: {4C441A70-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6J8ZVDq015469; Mon, 19 Jul 2010 11:35:31 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 19 Jul 2010 11:36:04 +0300 From: Yoav Nir To: IPsecme WG Date: Mon, 19 Jul 2010 11:35:30 +0300 Thread-Topic: QCD Interop test report Thread-Index: AcsnHWxu4V0R2XrvSz2aL71ea+jHmQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ran Canetti , Elad Moshe Subject: [IPsec] QCD Interop test report X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 08:35:21 -0000 Hi all The Quick Crash Detection protocol is one of the candidates for the failure= detection work item in our charter. I have implemented in my company's product with a private Notify type and a= VendorID, and up until a few months ago, this has been the only implementa= tion that I know of. As part of an undergraduate university program in computer science, a stude= nt from Tel Aviv University added this capability to StrongSwan on Linux. He has written his implementation independently - the only help I gave him = was to point him to the draft and coordinate the private Notify type. Early this month we met to test interoperability of our two implementation. One difference was immediately obvious. StrongSwan (at least the version he= was using) neither sends nor processes INVALID_SPI notifications. When the= CP gateway was restarted, and IPsec packets arrived, it sent INVALID_SPI n= otifications that were discarded. When the StrongSwan was restarted, the IP= sec packets were just discarded, with no notification sent. As a consequenc= e, crash detection was not very "quick". We had to wait until the liveness = check occurred, which was every 20 seconds. In response to the liveness check packet, the peer gateway did send the cor= rect QCD Notify payload, and the state was cleared on the initiator. Some bugs were discovered in both implementations: - The CP gateway did not send QCD in response to requests with MsgID 0. - The StrongSwan cleared the state successfully, and then had a segmentati= on fault - The CP gateway misinterpreted a one way unencrypted exchange (with INVAL= ID_IKE_SA and QCD) as a response, when the request was Informational All in all, seems like a successful test to me. I'd like to than Elad for the effort, and hope he gets a good grade for it.= Also, if he can locate and fix the crash, I encourage him to contribute hi= s implementation to the StrongSwan project. Yoav= From rsjenwar@gmail.com Mon Jul 19 03:24:03 2010 Return-Path: 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 08A923A67EA for ; Mon, 19 Jul 2010 03:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 y0EIYEYm5FvZ for ; Mon, 19 Jul 2010 03:24:01 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id BDDC53A67B8 for ; Mon, 19 Jul 2010 03:24:00 -0700 (PDT) Received: by qwe5 with SMTP id 5so1914170qwe.31 for ; Mon, 19 Jul 2010 03:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=tdgJFsycuwaw6zL1ayZX4CKFQ/As7+9hPBIXUCaRBxo=; b=mBk2HIGSN9NpXL8jdzPuqQI329p22cUF3hzELJBMC6uLGNfZC+1FwSUNaKtOIGIOeZ xfETwx2kuhc6SaVIyXsEx4orLGwKYt3ca2oT7ILocmsqWEQZ3V1Z8vR5jt+9DTufWIfp PAHDKblV+WdB9zgokbz6sKxtnshmNcJIGx3aU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RtASf48fBd//jTEWAMGxAqkkGqm4UP+M+Dm5ya8lXQvVRBpamr+nRIPHUgKPL2TcgT K6pqJgfyE3VxfPnbtqOgUxnC4OO4dpEq3cKm6FWMf093W80BxvqkIk2cIfDPhGhVumvB W7ps95eVpuhIqWs21o1cGZYHErO5U/LJNysDg= MIME-Version: 1.0 Received: by 10.224.72.37 with SMTP id k37mr4532333qaj.398.1279535054343; Mon, 19 Jul 2010 03:24:14 -0700 (PDT) Received: by 10.229.227.211 with HTTP; Mon, 19 Jul 2010 03:24:14 -0700 (PDT) Date: Mon, 19 Jul 2010 15:54:14 +0530 Message-ID: From: Raj Singh To: IPsecme WG Content-Type: multipart/alternative; boundary=00c09f899227645e5c048bbaf8a8 Subject: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 10:24:03 -0000 --00c09f899227645e5c048bbaf8a8 Content-Type: text/plain; charset=UTF-8 Hi Group, We have come up with new version of the "IPsec Cluster Solution"draft addressing comments which we got, the new version can be find here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs. We will submit the draft as soon as submission window re-opens. Please read the draft and give you comments before Maastricht meeting. Regards, Raj On Sun, Jul 11, 2010 at 4:39 PM, Raj Singh wrote: > Hi Group, > > We would like to present the HA design team's output for IPsec Cluster > Solution Draft before Maastricht meeting as > http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt > > This draft solves the main issues of IPsec Cluster Problem Statement draft > using a simple IKEv2 protocol extension, and provides implementation advice > for other issues. > > I sincerely thanks all the team members of HA Design Team for attending all > internal meetings and giving their valuable inputs and doing reviews. > My special thanks to Yaron and Yoav for their expert inputs and comments. I > would also like to thanks Paul for providing TeamSpeak server for conducting > internal design team meetings. > > The team started with these draft as inputs. > 1. http://tools.ietf.org/html/draft-kagarigi-ipsecme-ikev2-windowsync-00 - > G. Kalyani > 2. > http://www.ietf.org/id/draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txtJ. Arora > 3. http://www.ietf.org/id/draft-ietf-ipsecme-ipsec-ha-09.txt - Y. Nir - As > Input > > The current draft is based on [1], then it got enhanced and extended with > all team's contribution. > The problem and solution presented in [2], is more towards load balancing > than HA cluster. > Also this problem can be solved using IKEv2 REDIRECT mechanism. Also, this > solution requires IKEv2 > protocol change. So, this is deferred for now. > > I request the IPsecME group members to review and give comments on > http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt, > so that we can discuss this draft with more details in Maastricht meeting. > > Regards, > Raj Singh > > On Fri, Jun 18, 2010 at 11:56 AM, Yaron Sheffer wrote: > >> Hi, >> >> As promised, we have started a design team on IPsec HA. Paul and I have >> asked Raj Singh to lead the team. His job is to make sure that the team >> meets regularly in the next few weeks, and produces a good output document >> before the Maastricht face-to-face meeting. >> >> The initial membership of the team is: >> >> - Raj Singh (rsjenwar@gmail.com, lead) >> >> - Jitender Arora (JArora@acmepacket.com) >> - Min Huang (huangmin@huaweisymantec.com) >> - Dacheng Zhang (zhangdacheng@huawei.com) >> - Yoav Nir (ynir@checkpoint.com) >> - Yaron Sheffer (yaronf.ietf@gmail.com, observer) >> >> According to IETF rules (see >> http://www.ietf.org/iesg/statement/design-team.htm), every design team >> needs to have a mission statement. So here it is: >> >> Produce a high-level solution document that covers most or all of the >> issues raised by the HA problem statement (draft-ietf-ipsecme-ipsec-ha). Any >> solution should be applicable to different deployments, in order to >> accommodate the variety of existing and future IPsec products. Solutions >> should have a similar level of security as the IKE/IPsec suite. >> >> Another process reminder: the design team's output serves as input to the >> full WG, essentially like an individual draft. So all protocol decisions >> will eventually be made by the working group. >> >> Thanks, >> Yaron >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > --00c09f899227645e5c048bbaf8a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Group,

We have come up with new version of the "IPsec Cluste= r Solution"draft addressing comments which we got, the new version can= be find here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/= TempDocs.
We will submit the draft as soon as submission window re-opens.
Please r= ead the draft and give you comments before Maastricht meeting.

Regar= ds,
Raj


On Sun, Jul 11, 2010 at 4:= 39 PM, Raj Singh <rsjenwar@gmail.com> wrote:
Hi Group,

We would like to present the HA design team's output for IPsec= Cluster Solution Draft before Maastricht meeting as http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.tx= t

This draft solves the main issues of IPsec Cluster Problem Statement dr= aft using a simple IKEv2 protocol extension, and=C2=A0 provides implement= ation advice for other issues.

I sincerely thanks all the team membe= rs of HA Design Team for attending all internal meetings and giving their v= aluable inputs and doing reviews.
My special thanks to Yaron and Yoav for their expert inputs and comments. I= would also like to thanks Paul for providing TeamSpeak server for conducti= ng internal design team meetings.

The team started with these draft = as inputs.
1. http://tools.ietf.org/html/draft-kagarigi-ipsec= me-ikev2-windowsync-00 - G. Kalyani
2. http://www.ietf.org/id/draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00= .txt J. Arora
3. http://www.ietf.org/id/draft-ietf-ipsecme-ipsec-ha-09.txt - Y. Nir - As Input

The current draft is based on [1], then it go= t enhanced and extended with all team's contribution.
The problem and solution presented in [2], is more towards load balancing t= han HA cluster.
Also this problem can be solved using IKEv2 REDIRECT mec= hanism. Also, this solution requires IKEv2
protocol change. So, this is = deferred for now.

I request the IPsecME group members to review and give comments on http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev= 2-windowsync-03.txt, so that we can discuss this draft with more detail= s in Maastricht meeting.

Regards,
Raj Singh
=C2=A0
On Fri, Jun 18, 2010 at 11:56 AM, Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:
Hi,

As pro= mised, we have started a design team on IPsec HA. Paul and I have asked Raj= Singh to lead the team. His job is to make sure that the team meets regula= rly in the next few weeks, and produces a good output document before the M= aastricht face-to-face meeting.

The initial membership of the team is:

- Raj Singh (rsjenwar@gmail.com, lead)= =20

- Jitender Arora (JArora@acmepacket.com)
- Min Huang (huangmin@huaweisymantec.= com)
- Dacheng Zhang (zhangdacheng@huawei.com)
- Yoav Nir (ynir@checkpoint.com)
- Yaron Sheffer (<= a href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail= .com, observer)

According to IETF rules (see http://www.ietf.org/iesg/statement/d= esign-team.htm), every design team needs to have a mission statement. S= o here it is:

Produce a high-level solution document that covers most or all of the i= ssues raised by the HA problem statement (draft-ietf-ipsecme-ipsec-ha). Any= solution should be applicable to different deployments, in order to accomm= odate the variety of existing and future IPsec products. Solutions should h= ave a similar level of security as the IKE/IPsec suite.

Another process reminder: the design team's output serves as input = to the full WG, essentially like an individual draft. So all protocol decis= ions will eventually be made by the working group.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron=20

_______________________________________________
IPsec mailing l= ist
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--00c09f899227645e5c048bbaf8a8-- From yaronf.ietf@gmail.com Mon Jul 19 09:08:48 2010 Return-Path: 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 F1EAF3A6934 for ; Mon, 19 Jul 2010 09:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Xhc5PhGLFVTm for ; Mon, 19 Jul 2010 09:08:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 968763A686E for ; Mon, 19 Jul 2010 09:08:42 -0700 (PDT) Received: by wyf22 with SMTP id 22so330667wyf.31 for ; Mon, 19 Jul 2010 09:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3WAIxGwD2KW/HpKq6MxTvZlPWDm2eCXaaEeVXpmkYkA=; b=KaTwiq4Vu8XAEnVLwE1ZsXcBrpHB7SxRrM8aVr+t5f2gykoLq3BfpIz4fD8ZWK9d9V OM3xYG2Z0HoHvQIk3xlkngsnmeqnK3osBuRaADFfdk8LRXMTJJXJBc+I/QZPckYIGChz ifrLpMsago/AP84BSPpYpvzaLzyVHAM0cQZgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZgjSjjq6RLQsj6+pM8Jvk6Zx4L4BFKK2NoxVWItuG2huuDng5Q9rEWWIR1VN1U28mK KUZOwDf2NhhJg+LKWimSRaoIP8FogWLXM0DLOUFI0GAicYgCH2E9QIhBZuxsP26uyzjK 40u709pVWP+l+Qw10Bpa2oev9Aq3zO/ObZtPE= Received: by 10.227.142.132 with SMTP id q4mr4260544wbu.90.1279555733169; Mon, 19 Jul 2010 09:08:53 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-177-34-148.red.bezeqint.net [79.177.34.148]) by mx.google.com with ESMTPS id b18sm41976471wbb.7.2010.07.19.09.08.51 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 09:08:52 -0700 (PDT) Message-ID: <4C447891.8060708@gmail.com> Date: Mon, 19 Jul 2010 19:08:49 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Raj Singh References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:08:48 -0000 Hi everyone, Please note that most of the discussion in Maastricht will be around this draft, so you are strongly encouraged to read it. For those who cannot make it to Holland, please use the IETF audio streaming to listen in, and Jabber to participate in real time. More details here: http://www.ietf.org/meeting/78/remote-participation.html. We will *not* have WebEX for IPsecME this time. Thanks, Yaron On 07/19/2010 01:24 PM, Raj Singh wrote: > Hi Group, > > We have come up with new version of the "IPsec Cluster Solution"draft > addressing comments which we got, the new version can be find here: > http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs. > > We will submit the draft as soon as submission window re-opens. > Please read the draft and give you comments before Maastricht meeting. > > Regards, > Raj > > > On Sun, Jul 11, 2010 at 4:39 PM, Raj Singh > wrote: > > Hi Group, > > We would like to present the HA design team's output for IPsec > Cluster Solution Draft before Maastricht meeting as > http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt > > This draft solves the main issues of IPsec Cluster Problem Statement > draft using a simple IKEv2 protocol extension, and provides > implementation advice for other issues. > > I sincerely thanks all the team members of HA Design Team for > attending all internal meetings and giving their valuable inputs and > doing reviews. > My special thanks to Yaron and Yoav for their expert inputs and > comments. I would also like to thanks Paul for providing TeamSpeak > server for conducting internal design team meetings. > > The team started with these draft as inputs. > 1. > http://tools.ietf.org/html/draft-kagarigi-ipsecme-ikev2-windowsync-00 - > G. Kalyani > 2. > http://www.ietf.org/id/draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txt > J. Arora > 3. http://www.ietf.org/id/draft-ietf-ipsecme-ipsec-ha-09.txt - Y. > Nir - As Input > > The current draft is based on [1], then it got enhanced and extended > with all team's contribution. > The problem and solution presented in [2], is more towards load > balancing than HA cluster. > Also this problem can be solved using IKEv2 REDIRECT mechanism. > Also, this solution requires IKEv2 > protocol change. So, this is deferred for now. > > I request the IPsecME group members to review and give comments on > http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt, > so that we can discuss this draft with more details in Maastricht > meeting. > > Regards, > Raj Singh > On Fri, Jun 18, 2010 at 11:56 AM, Yaron Sheffer > > wrote: > > Hi, > > As promised, we have started a design team on IPsec HA. Paul and > I have asked Raj Singh to lead the team. His job is to make sure > that the team meets regularly in the next few weeks, and > produces a good output document before the Maastricht > face-to-face meeting. > > The initial membership of the team is: > > - Raj Singh (rsjenwar@gmail.com , lead) > > - Jitender Arora (JArora@acmepacket.com > ) > - Min Huang (huangmin@huaweisymantec.com > ) > - Dacheng Zhang (zhangdacheng@huawei.com > ) > - Yoav Nir (ynir@checkpoint.com ) > - Yaron Sheffer (yaronf.ietf@gmail.com > , observer) > > According to IETF rules (see > http://www.ietf.org/iesg/statement/design-team.htm), every > design team needs to have a mission statement. So here it is: > > Produce a high-level solution document that covers most or all > of the issues raised by the HA problem statement > (draft-ietf-ipsecme-ipsec-ha). Any solution should be applicable > to different deployments, in order to accommodate the variety of > existing and future IPsec products. Solutions should have a > similar level of security as the IKE/IPsec suite. > > Another process reminder: the design team's output serves as > input to the full WG, essentially like an individual draft. So > all protocol decisions will eventually be made by the working group. > > Thanks, > Yaron > > _______________________________________________ > 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 wwwrun@core3.amsl.com Mon Jul 19 09:27:03 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D28CD3A6934; Mon, 19 Jul 2010 09:27:03 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100719162703.D28CD3A6934@core3.amsl.com> Date: Mon, 19 Jul 2010 09:27:03 -0700 (PDT) Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Document Action: 'IPsec Cluster Problem Statement' to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:27:03 -0000 The IESG has approved the following document: - 'IPsec Cluster Problem Statement ' as an Informational RFC This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-09.txt Technical Summary This document describes the problems associated with clustering of IKE/IPsec VPN endpoints using the existing set of standards. It is claimed that the amount and volatility of IKE/IPsec state result in numerous challenges for such clustering. The document defines terminology for high availability and load sharing clusters implementing IKE and IPsec, and describes gaps in the existing standards. Working Group Summary There was no controversy other than a prolonged discussion on terminology. Document Quality This is a problem statement, not a protocol. However it is noted that the vast majority of IPsec VPN products support some form of clustering, and there is a strong feeling in the working group that this document is a step forward in allowing better interoperability of clustered systems. Personnel Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd. Sean Turner (turners@ieca.com) is Responsible Area Director? From paul.hoffman@vpnc.org Mon Jul 19 10:02:21 2010 Return-Path: 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 062703A6B21 for ; Mon, 19 Jul 2010 10:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] 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 QpiM5UcSp7qV for ; Mon, 19 Jul 2010 10:02:20 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2CF763A68A4 for ; Mon, 19 Jul 2010 10:02:20 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6JH2WCD096834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jul 2010 10:02:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C447891.8060708@gmail.com> References: <4C447891.8060708@gmail.com> Date: Mon, 19 Jul 2010 10:02:31 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:02:21 -0000 First off: thank you to the design team for the work you put into this. The rest of the WG didn't see this, but the group worked hard and met often. One of the things that interests me as chair is: does this proposed protocol meet the requirement set out in our RFC-to-be ? If not, what is missing, and can it be added easily to the proposed protocol? This will definitely be one of the points of discussion a week from now in Maastricht, but folks can start discussing it here on the list now in preparation for the meeting. --Paul Hoffman, Director --VPN Consortium From yaronf.ietf@gmail.com Mon Jul 19 10:25:59 2010 Return-Path: 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 5D53C3A687D for ; Mon, 19 Jul 2010 10:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 pLfnNjo7KnJn for ; Mon, 19 Jul 2010 10:25:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 40ACB3A67AC for ; Mon, 19 Jul 2010 10:25:58 -0700 (PDT) Received: by wwb39 with SMTP id 39so349638wwb.13 for ; Mon, 19 Jul 2010 10:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=U+A7/ekK22z+R217B5UEf5qPh8YVCVmjGgtVTriUmvU=; b=AljlD6te/WIVL/7Et48VDlPUp9/2hYa87AfEiZsMBl61JJbIXR9dCWkNnV/TV7/h3j UGlpvJYojgSsTkr/xwMKBUgANGLeCRdg6yFlAb+1zQuwwhFa55W4dsLvTW7K48ky3T/I KtobGmqCOh7NqceEO638trp/AEYqnOy2YZnc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rNoIElEVQBB/ihZIURERES9pQLGIXuFCrUqhTqyvgIubIo1kcjWvIHuhQGRCfr6yyv nxTBhA2sVYINrA/IAxuwpMse+yZZ3ibd6XTLsJuaiaPabY3zKvBowSmzBsgMEIWNbFW/ B1IozrheQhA33cV2iYeDhTGYLL3q5W/PE04a8= Received: by 10.227.138.5 with SMTP id y5mr4347175wbt.204.1279560372339; Mon, 19 Jul 2010 10:26:12 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-177-34-148.red.bezeqint.net [79.177.34.148]) by mx.google.com with ESMTPS id g37sm42441067wbg.15.2010.07.19.10.26.10 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 10:26:11 -0700 (PDT) Message-ID: <4C448AB1.5080305@gmail.com> Date: Mon, 19 Jul 2010 20:26:09 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Hoffman References: <4C447891.8060708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:25:59 -0000 Sec. 3 of the draft lists each of the issues described in the Problem Statement, and explains how it is resolved. Thanks, Yaron On 07/19/2010 08:02 PM, Paul Hoffman wrote: > First off: thank you to the design team for the work you put into this. The rest of the WG didn't see this, but the group worked hard and met often. > > One of the things that interests me as chair is: does this proposed protocol meet the requirement set out in our RFC-to-be? If not, what is missing, and can it be added easily to the proposed protocol? > > This will definitely be one of the points of discussion a week from now in Maastricht, but folks can start discussing it here on the list now in preparation for the meeting. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Mon Jul 19 10:41:45 2010 Return-Path: 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 8D2F73A6949 for ; Mon, 19 Jul 2010 10:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.347 X-Spam-Level: X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 n0BqQHpmkHLB for ; Mon, 19 Jul 2010 10:41:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 18E2E3A686E for ; Mon, 19 Jul 2010 10:41:44 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6JHftIj099298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 10:41:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C448AB1.5080305@gmail.com> References: <4C447891.8060708@gmail.com> <4C448AB1.5080305@gmail.com> Date: Mon, 19 Jul 2010 10:41:54 -0700 To: Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:41:45 -0000 At 8:26 PM +0300 7/19/10, Yaron Sheffer wrote: >Sec. 3 of the draft lists each of the issues described in the Problem Statement, and explains how it is resolved. Exactly right. The question to the group is: do you agree with the matching? If not, what do you see as the differences? --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Mon Jul 19 23:40:42 2010 Return-Path: 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 AFBBC3A6BE8 for ; Mon, 19 Jul 2010 23:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] 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 1zy8mNUCbkVa for ; Mon, 19 Jul 2010 23:40:36 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 66F5F3A69E5 for ; Mon, 19 Jul 2010 23:40:35 -0700 (PDT) X-CheckPoint: {4C455103-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6K6eiDq018725; Tue, 20 Jul 2010 09:40:44 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 20 Jul 2010 09:41:16 +0300 From: Yoav Nir To: Paul Hoffman Date: Tue, 20 Jul 2010 09:41:15 +0300 Thread-Topic: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] Thread-Index: Acsn1o0/nBjS1GOGRHiFoO2U5b/oRQ== Message-ID: <1F908DCC-0ABC-4653-9E9B-C8772A2B3D2E@checkpoint.com> References: <4C447891.8060708@gmail.com> <4C448AB1.5080305@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 06:40:42 -0000 I'd like to point out that section 3 is kind of skeletal at this point, and= I expect that in the final document, each bullet point will be expanded to= its own subsection. I think in the end, section 3 will contain most of the= volume of the document. We've found that (at least in our opinion) most of the problems in the PS d= ocument can be addressed with a particular interpretation of the existing s= tandards, rather than new protocol extensions. The exception is expanded in= section 4. In future iterations of the document (hopefully as a WG docume= nt) each of the bullet points in section 3 will be expanded to a subsection= with MUSTs and SHOULDs for both the cluster implementation and its peers. Of course, discussion in the group may lead to a realization that creative = interpretation of existing documents is not enough. In that case more exten= sion can be proposed and added to the document, much the same way that more= problems were added to the PS draft after Anaheim. On Jul 19, 2010, at 8:41 PM, Paul Hoffman wrote: > At 8:26 PM +0300 7/19/10, Yaron Sheffer wrote: >> Sec. 3 of the draft lists each of the issues described in the Problem St= atement, and explains how it is resolved. >=20 > Exactly right. The question to the group is: do you agree with the matchi= ng? If not, what do you see as the differences? >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From wwwrun@rfc-editor.org Tue Jul 20 14:04:56 2010 Return-Path: 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 2EE1A3A6A5C; Tue, 20 Jul 2010 14:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 UFSZfyC7wWAg; Tue, 20 Jul 2010 14:04:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id F381F3A6B2B; Tue, 20 Jul 2010 14:04:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 01988E06C4; Tue, 20 Jul 2010 14:05:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100720210511.01988E06C4@rfc-editor.org> Date: Tue, 20 Jul 2010 14:05:10 -0700 (PDT) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 5930 on Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:04:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5930 Title: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol Author: S. Shen, Y. Mao, NSS. Murthy Status: Informational Stream: IETF Date: July 2010 Mailbox: shenshuo@cnnic.cn, yumao9@gmail.com, ssmurthy.nittala@freescale.com Pages: 6 Characters: 12217 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-aes-ctr-ikev2-07.txt URL: http://www.rfc-editor.org/rfc/rfc5930.txt This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ynir@checkpoint.com Tue Jul 20 17:45:06 2010 Return-Path: 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 1655A3A69BB for ; Tue, 20 Jul 2010 17:45:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -6.67 X-Spam-Level: X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=3.929, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.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 EstSMyyYl-Mc for ; Tue, 20 Jul 2010 17:45:04 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279673106-8617-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E5AA63A6951 for ; Tue, 20 Jul 2010 17:45:03 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2010 00:45:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6L0inou013379 for ; Wed, 21 Jul 2010 00:45:04 GMT Received: from mail pickup service by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 15:02:13 -0700 Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 23:45:02 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 01:41:10 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 06:41:05 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6f1Xm016019; Tue, 20 Jul 2010 06:41:05 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-e.cisco.com with ESMTP; 20 Jul 2010 06:41:04 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07BE13A6BEC; Mon, 19 Jul 2010 23:40:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBBC3A6BE8 for ; Mon, 19 Jul 2010 23:40:41 -0700 (PDT) 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 1zy8mNUCbkVa for ; Mon, 19 Jul 2010 23:40:36 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 66F5F3A69E5 for ; Mon, 19 Jul 2010 23:40:35 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6K6eiDq018725; Tue, 20 Jul 2010 09:40:44 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 20 Jul 2010 09:41:16 +0300 Date: Tue, 20 Jul 2010 01:41:15 -0500 Message-ID: <1F908DCC-0ABC-4653-9E9B-C8772A2B3D2E@checkpoint.com> In-Reply-To: References: <4C447891.8060708@gmail.com> <4C448AB1.5080305@gmail.com> From: "Yoav Nir" To: "Paul Hoffman" Cc: IPsecme WG Subject: Re: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 00:45:06 -0000 This is a multi-part message in MIME format... ------------=_1279673106-8617-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279673106-8617-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E5AA63A6951 for ; Tue, 20 Jul 2010 17:45:03 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 3273 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACbgRUyrRN+J/2dsb2JhbACfdXGlXpsRhTIEhACHDg Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2010 00:45:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6L0inou013379 for ; Wed, 21 Jul 2010 00:45:04 GMT Received: from mail pickup service by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 15:02:13 -0700 Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 23:45:02 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 01:41:10 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27D6.89E28700" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 06:41:05 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6f1Xm016019; Tue, 20 Jul 2010 06:41:05 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-e.cisco.com with ESMTP; 20 Jul 2010 06:41:04 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07BE13A6BEC; Mon, 19 Jul 2010 23:40:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBBC3A6BE8 for ; Mon, 19 Jul 2010 23:40:41 -0700 (PDT) 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 1zy8mNUCbkVa for ; Mon, 19 Jul 2010 23:40:36 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 66F5F3A69E5 for ; Mon, 19 Jul 2010 23:40:35 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6K6eiDq018725; Tue, 20 Jul 2010 09:40:44 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 20 Jul 2010 09:41:16 +0300 Content-class: urn:content-classes:message Subject: Re: [IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started] Date: Tue, 20 Jul 2010 01:41:15 -0500 Message-ID: <1F908DCC-0ABC-4653-9E9B-C8772A2B3D2E@checkpoint.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: <1F908DCC-0ABC-4653-9E9B-C8772A2B3D2E@checkpoint.com> Thread-Topic: [IPsec] New version of IPsec Cluster Solution Draft posted[earliar, HA design team started] Thread-Index: Acsn1o0/nBjS1GOGRHiFoO2U5b/oRQ== References: <4C447891.8060708@gmail.com> <4C448AB1.5080305@gmail.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Yoav Nir" Sender: To: "Paul Hoffman" Cc: "IPsecme WG" X-OriginalArrivalTime: 20 Jul 2010 06:45:02.0157 (UTC) FILETIME=[1442DFD0:01CB27D7] This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27D6.89E28700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd like to point out that section 3 is kind of skeletal at this point, = and I expect that in the final document, each bullet point will be = expanded to its own subsection. I think in the end, section 3 will = contain most of the volume of the document. We've found that (at least in our opinion) most of the problems in the = PS document can be addressed with a particular interpretation of the = existing standards, rather than new protocol extensions. The exception = is expanded in section 4. In future iterations of the document = (hopefully as a WG document) each of the bullet points in section 3 will = be expanded to a subsection with MUSTs and SHOULDs for both the cluster = implementation and its peers. Of course, discussion in the group may lead to a realization that = creative interpretation of existing documents is not enough. In that = case more extension can be proposed and added to the document, much the = same way that more problems were added to the PS draft after Anaheim. On Jul 19, 2010, at 8:41 PM, Paul Hoffman wrote: > At 8:26 PM +0300 7/19/10, Yaron Sheffer wrote: >> Sec. 3 of the draft lists each of the issues described in the Problem = Statement, and explains how it is resolved. >=20 > Exactly right. The question to the group is: do you agree with the = matching? If not, what do you see as the differences? >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01CB27D6.89E28700 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgEGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAYQAAAFJlOiBbSVBzZWNdIE5ldyB2 ZXJzaW9uIG9mIElQc2VjIENsdXN0ZXIgU29sdXRpb24gRHJhZnQgcG9zdGVkIFtlYXJsaWFyLCBI QSBkZXNpZ24gdGVhbSBzdGFydGVkXQA6IgEFgAMADgAAANoHBwAUAAEAKQAPAAIANwEBIIADAA4A AADaBwcAFAABACwAKQACAFQBAQmAAQAhAAAAMUNFQTAzMTU5MDFDNDY0ODg2RDg5QzE4NUUzMzM4 RDgADAcBA5AGAJwLAAAoAAAAAwA2AAAAAABAADkAgHfdjNYnywEeAD0AAQAAAAUAAABSZTogAAAA AB4AcAABAAAAXAAAAFtJUHNlY10gTmV3IHZlcnNpb24gb2YgSVBzZWMgQ2x1c3RlciBTb2x1dGlv biBEcmFmdCBwb3N0ZWRbZWFybGlhciwgSEEgZGVzaWduIHRlYW0gc3RhcnRlZF0AAgFxAAEAAAAW AAAAAcsn1o0/nBjS1GOGRHiFoO2U5b/oRQAAHgAaDAEAAAAXAAAAaXBzZWMtYm91bmNlc0BpZXRm Lm9yZwAAHgAdDgEAAABdAAAAW0lQc2VjXSBOZXcgdmVyc2lvbiBvZiBJUHNlYyBDbHVzdGVyIFNv bHV0aW9uIERyYWZ0IHBvc3RlZCBbZWFybGlhciwgSEEgZGVzaWduIHRlYW0gc3RhcnRlZF0AAAAA AgEJEAEAAADJBAAAxQQAAB0IAABMWkZ1IRYOCAMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKk A+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7 GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSQAnZCBsaWtlIOB0byBwbwuABUAIYB0FQHQT4AVAFBBj dGmRAiAgMyAEACBrC4DZHRBvZh6QHVBsFCAHQN4gHnEeUB9BHbMsIHAfkfRJIA7AcB6xHkQLgB5B DR1gZguAIFFkb2N1CweAITJlANBoIGJ1/mwgIR2lA/AkcCRAHWAh0SchcQmAHXJpdAQgb3fRA6Bz dWIepS4hoSCx7G5rIoYJ8GQhUB6oJSPXBaACMAtxIARgcx3xH9C9IsJ2BvAjkSqWI2YuCqLDCoQK gFdlJ3Yi4Qhg2x+RHlMoHnEgIGEqcSKRWwhhHgBwC4Ae4SkqS3CzA2ACYGVtBCAilVAF8I8jZinA A5ElcWFkZBgg/wQQJgED8B5QIHAdoArAHtD/I4ALYAXAHdEEkDCwIDEe088qpQ7ABAAe0G5nHpAB kOsfkAsRcyFQch5wItAFwPseUQOgbgfRMLEdgBeRIcFXDrAAgQIgcyeAVDXTY35lBTAe4h9BJaci kR6mNPcngBzgA6BmHiAIcB1gJmDfBJA1MyaBK5wuQGgvYAEQnSRheSBwBCAz0FdHI1f/L9AkAyql JFoxIyjtJX0z0MMm6DN0TVVTVD8xH5HAU0hPVUxEBCACEO8FwAbgM6EiwmMKQCpwEoH/B3ALUDEA I7E1NCFyJmIh8PcEkDlgLIpPH9AFoAhwFBD9IVBkBAAjgAQQOjMipAnA9QhgcCpAYT8ALpFDpRgg +QdAaXo1NB5TBQAkAB7Qvy1xNK81+CNmMSEEIG44YPMogQhgZ2gngU3GLrAdYP8EYDyRONcyZjCx HbAzQiFybzLhJgQruiFQbRrQRqRzemErUXdMUR5TUtMwt3f/BJAyw1U4MbI3QAGAIHABgP0SgUEj ICLQB3Ase0m1A6BiSiRgIDE5IVAB0DGGMCFRBUA4OjQxMaDSTSFQUGFcsUgfwARQpQORdzhRZTos ij4QwAldkjI2XfEgKzAzcjAWUDcvXOBhcF1RWXsKwB7xUyLQASASgV8aPvtgMAZgYyeAHyArhloj HTD/KnA6gUBZBAEKUAQgAQAE8v8lcDsTMXMwxAYANSFHwyFU/yHRC2IEID6AB+AmYB8yMxE7BvAt cGQsdWAwX9ZFeH0A0HQ+8QUQUcAsYDmDcV9mUU2UVXRL5AQAOiNRIH55CGAgcAnCM3QiwgDAdHsT 0DZRPxzgH9BRQSFQd/8eYm6lFBAywQQgK7MGkGKRkwnwOfBzP2reLS1eSnkhUERpGCAewAWwc9hW 3FBOEiEAgBfBaSOQX9aeX3ffeO95ul/WSVAeod9MMQMQNlJlAnrLQAiQADCaLgWwZ1/WbIB0cG5w qC8vd37ALn1GL3ui3QOBL2UCC4ACEC8FIB6hXWreUzJxOAAdEGI/AEPVItBjKABQHcNUOGAgUetj wQhxdD8AR2hBV1Ese/95v4afef8KgHtPfFV87yyxF35Pf1+AbX2OwAAAAB4ANRABAAAANgAAADwx RjkwOERDQy0wQUJDLTQ2NTMtOUU5Qi1DODc3MkEyQjNEMkVAY2hlY2twb2ludC5jb20+AAAAHgA5 EAEAAADFAAAAPEFBTkxrVGluc0lob3YzYVZ1S3FWUmY3Z21IRzVvRzcwZTVPb002eVdjN05BUUBt YWlsLmdtYWlsLmNvbT48NEM0NDc4OTEuODA2MDcwOEBnbWFpbC5jb20+IDxwMDYyNDA4MTJjODZh MzUwMjIzNTJAWzEwLjIwLjMwLjE1OF0+PDRDNDQ4QUIxLjUwODAzMDVAZ21haWwuY29tPiA8cDA2 MjQwODE0Yzg2YTNlYzA2YmM0QFsxMC4yMC4zMC4xNThdPgAAAAAeAEIQAQAAACcAAAA8cDA2MjQw ODE0Yzg2YTNlYzA2YmM0QFsxMC4yMC4zMC4xNThdPgAAHgBDEAEAAAAtAAAAPG1haWx0bzppcHNl Yy1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscD4AAAAAHgBEEAEAAABgAAAAPGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM+LDxtYWlsdG86aXBzZWMtcmVxdWVz dEBpZXRmLm9yZz9zdWJqZWN0PXN1YnNjcmliZT4AHgBFEAEAAABiAAAAPGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM+LDxtYWlsdG86aXBzZWMtcmVxdWVzdEBpZXRm Lm9yZz9zdWJqZWN0PXVuc3Vic2NyaWJlPgAAAAsA8hAAAEAAHwDzEAEAAADOAAAAUgBlACUAMwBB ACAAWwBJAFAAcwBlAGMAXQAgAE4AZQB3ACAAdgBlAHIAcwBpAG8AbgAgAG8AZgAgAEkAUABzAGUA YwAgAEMAbAB1AHMAdABlAHIAIABTAG8AbAB1AHQAaQBvAG4AIABEAHIAYQBmAHQAIABwAG8AcwB0 AGUAZAAgAFsAZQBhAHIAbABpAGEAcgAsACAASABBACAAZABlAHMAaQBnAG4AIAB0AGUAYQBtACAA cwB0AGEAcgB0AGUAZABdAC4ARQBNAEwAAAAAAEAABzCsfViK1ifLAUAACDC6L/wH1yfLAQMA3j+v bwAAAwDfP/////8DAPE/AAAAAB4A+D8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB +T8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAHgD6PwEAAAAVAAAAU3lz dGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA AAAAAC4AAAADAP0/5AQAAAMAGUAAAAEAAwAaQAAAAQAeADBAAQAAABcAAABpcHNlYy1ib3VuY2Vz QGlldGYub3JnAAAeADFAAQAAABQAAAB5bmlyQGNoZWNrcG9pbnQuY29tAB4AOEABAAAAAgAAAC4A AAAeADlAAQAAAAIAAAAuAAAACwApAAAAAAALACMAAAAAAAMABhDJ4a9ZAwAHEPwEAAADABAQAAAA AAMAERAAAAAAHgAIEAEAAABlAAAASURMSUtFVE9QT0lOVE9VVFRIQVRTRUNUSU9OM0lTS0lORE9G U0tFTEVUQUxBVFRISVNQT0lOVCxBTkRJRVhQRUNUVEhBVElOVEhFRklOQUxET0NVTUVOVCxFQUNI QlVMTEVUUAAAAAACAX8AAQAAADYAAAA8MUY5MDhEQ0MtMEFCQy00NjUzLTlFOUItQzg3NzJBMkIz RDJFQGNoZWNrcG9pbnQuY29tPgAAAJpH ------_=_NextPart_001_01CB27D6.89E28700-- ------------=_1279673106-8617-1-- From kivinen@iki.fi Sun Jul 25 07:30:44 2010 Return-Path: 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 A67873A6886 for ; Sun, 25 Jul 2010 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 8nc68TIB5gEW for ; Sun, 25 Jul 2010 07:30:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 500E93A68A9 for ; Sun, 25 Jul 2010 07:30:41 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o6PEUwC4025771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Jul 2010 17:30:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o6PEUwXt005423; Sun, 25 Jul 2010 17:30:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19532.19106.297495.280881@fireball.kivinen.iki.fi> Date: Sun, 25 Jul 2010 17:30:58 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 41 min X-Total-Time: 63 min Subject: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 14:30:44 -0000 I have read the the draft now, altought my paper version was -03 (last version from the ietf repository), but noticed before starting to read it that there was this newer version in the hidden web-page (where you can even download it if you find the fine print version saying "original format" download link). I have one big issue with the document which is very hard to fix, and then two smaller attacks which may (and needs) to be fixed. The big issue is that the draft does not provide solution to case where the IKEv2 SA messages missed actually did something. It seems to completely assume that all IKEv2 SA messages are DPD messages meaning it does not matter if we processed them or not, and because of that only syncs the message IDs and not what was done using those messages. In sensible implementation DPD messages are NOT majority of the messages. DPD messages is only sent when the traffic was changed to one way or if there is some other reason to belive the other end is not up and working anymore. If there is normal IPsec traffic flowing through the any of the IPsec SAs tied to the IKE SA there is no reason to send DPD ever. This means that in normal case rekeys, deletes and create child requests are more frequent than DPD messages. Because of not solving the problem this protocol can cause the IKEv2 peers to be out of sync from each other. I.e. other end might think he has new IPsec SA he has successfully created with the other end, but then other end looses that when the failorver happens, or peer might have deleted some IPsec SAs only to find that they were not deleted, or it might have rekeyed some IPsec SA but other end does not know that etc. The current draft does not explain anything how those cases should be handled. We had long discussion and text editing to get the IKEv2bis document take care of the simultaneous exchange cases properly and if we want to do the IKEv2 SA sync here we must add similar processing rules for each of those case here too. This will make the protocol and the processing rules much more complex. We also should make sure there is some way to detect those cases, hopefully before the IPsec SA is used for real traffic. The IKEv2 protocol tries very hard to be reliable and make sure that SA state cannot get out of sync between the two peers and adding protocol extension which makes them out of sync very easily is not really an option. ---------------------------------------------------------------------- The first smaller point is that the protocol as currently written allows very easy way to replay SYNC_SA_COUNTER_INFO requests as there is no protection for them (they have message ID 0 and the nonce only protects the response not the request). As the recipient of the SYNC_SA_COUNTER_INFO message actually does some processing and updates its state (i.e. it marks missing messages so they do not going to get reply anymore) this means this allows a way to actively delete IKEv2 SAs requests. I.e. when failover has once happened and the attacker has seen the SYNC_SA_COUNTER_INFO message with message id 0 on the wire it will store that for later attack use. Now whenever the attacker wants the peer to forget one message he first deleted it on the wire, then waits for next exchange to come and when it is processed he resends the SYNC_SA_COUNTER_INFO which causes the other peer to ignore the fact that it hasn't seen that message yet. >From section 8: o The peer should not wait for pending request also. For example if window size is 5 and peer window is 3-7 and if peer has received requests 4,5,6,7 but not 3 then it should send the EXPECTED_RECV_REQ_MESSAGE_ID as 8 and should not wait for 3 anymore. ---------------------------------------------------------------------- Second smaller point is that for IPsec SAs there is bit similar attack but in this case the attacker will use the SYNC_SA_COUNTER_INFO messages to reset the IPsec SA replay counters to the values they had when failover happend. He can do this at will and then he can replay anything that was sent after that. This should be quite easy to fix by adding text saying that when "The peer will update its Inbound SA Counters for each IPsec SA" it will do that only if the SA counters in the message were smaller than what he had himself. This of course means that the failover host needs to increment the counter by large enough number or that the protocol is modified so that the peer will tell his bigger numbers back. ---------------------------------------------------------------------- The document has huge number of typos, and misplaced punctuation characters, repeated text etc, and I don't want to confuse those 3 bigger points by including them in this message. For solving the big issue and the first smaller issue, I would think the easiest way would be to remove the IKE SA message ID syncing completely. The cluster can quite easily be made so that the IKE SA message counters are updated every time when IKE SA message is sent, as in most cases the IEK SA message update is needed to be sent to the other cluster member anyways, as it affects the IPsec SAs (i.e. created, deleted or rekeyed them). I.e. it does not require protocol modifications, just smart and good implementations. The IPsec SA replay counter problem is something that cannot be very easily be kept completely in sync with cluster members as there is so much more IPsec traffic than there is IKE SA traffic. Because of this it might be better to modify the protocol to only solve that problem. -- kivinen@iki.fi From ynir@checkpoint.com Sun Jul 25 07:55:17 2010 Return-Path: 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 B2B0A3A67B7 for ; Sun, 25 Jul 2010 07:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599] 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 L5EaHAJjmvYa for ; Sun, 25 Jul 2010 07:55:17 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id AC5AA3A67FE for ; Sun, 25 Jul 2010 07:55:16 -0700 (PDT) X-CheckPoint: {4C4C5C3D-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6PEtZDq011604; Sun, 25 Jul 2010 17:55:35 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 25 Jul 2010 17:56:06 +0300 From: Yoav Nir To: Tero Kivinen Date: Sun, 25 Jul 2010 17:55:32 +0300 Thread-Topic: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04 Thread-Index: AcssCYJGtXxlJnCgQC2w40AZvZtG0A== Message-ID: References: <19532.19106.297495.280881@fireball.kivinen.iki.fi> In-Reply-To: <19532.19106.297495.280881@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 14:55:17 -0000 Thanks for the extensive review, Tero. I haven't had time to read it through yet, but I would like to respond to o= ne point in this (below) On Jul 25, 2010, at 4:30 PM, Tero Kivinen wrote: > The big issue is that the draft does not provide solution to case > where the IKEv2 SA messages missed actually did something. It seems to > completely assume that all IKEv2 SA messages are DPD messages meaning > it does not matter if we processed them or not, and because of that > only syncs the message IDs and not what was done using those messages. I agree that the draft in its current form glosses over the fact that the m= issing IKE exchanges did something, like setting up a child SA, or tearing = one down. I don't believe there is any way you can set up a cluster so that= this never ever happens. You can make it rare, but not completely eliminat= e it. When this does happen, we have two things we might prescribe. We can detect= this and delete the IKE SA along with all associated child SAs, or we can = try to recover. draft-kagarigi-ipsecme-ikev2-windowsync takes the latter wa= y. To get recovery actually working we need some more "stuff". We need to acc= ept this case of mis-matched states between peers, and work towards making = them better matched, by allowing an implementation to inform its peer that = the SA that is using is unknown - an obvious thing is to send an INVALID_SP= I notify in an INFORMATIONAL exchange, or maybe add a DELETE_ALL_CHILDREN n= otification. The draft will need text that discusses how this actually conv= erges in a matched IKE SA. It should be noted (in the draft!) that this changes some assumptions about= IKEv2 state.=20 Yoav= From ynir@checkpoint.com Mon Jul 26 01:33:50 2010 Return-Path: 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 B098C3A6A67 for ; Mon, 26 Jul 2010 01:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599] 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 BOLzgXkbOisF for ; Mon, 26 Jul 2010 01:33:49 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id E6EB93A6AC0 for ; Mon, 26 Jul 2010 01:33:43 -0700 (PDT) X-CheckPoint: {4C4D5448-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6Q8Y2Dq001508 for ; Mon, 26 Jul 2010 11:34:02 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 26 Jul 2010 11:34:33 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Mon, 26 Jul 2010 11:34:01 +0300 Thread-Topic: Some back-of-the-envelope calculations Thread-Index: AcssnV9QNYe7R2dZTNOXnibXWuBxvg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Some back-of-the-envelope calculations X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:33:50 -0000 In today's session there was an disagreement between Yaron and Tero about h= ow likely it is that messages are missing. Let's assume our cluster has tunnels with 10,000 peers, and that we do Live= ness Check (DPD) every 20 seconds (StrongSwan default) Also, let's assume that we synch every 0.1 seconds, and detect a failure af= ter 10 missed messages (1 second) We have 500 liveness checks every second (10,000 / 20), but at the time of = the failure on average 25 messages (half of the amount of liveness checks i= n a 0.1 second period). So with Tero's way, 25 IKE SAs are mismatched (the other 475 didn't get a r= esponse, so the peer is still retransmitting) That's 25 IKE SAs torn down out of 10,000 (0.25%, or 1 in 400) Whether this is acceptable or not, is vendor-specific, and YMMV Yoav From bew@cisco.com Mon Jul 26 02:08:47 2010 Return-Path: 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 3B6023A68B2 for ; Mon, 26 Jul 2010 02:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 R4+0ZKJewr0F for ; Mon, 26 Jul 2010 02:08:46 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E46F73A6A50 for ; Mon, 26 Jul 2010 02:08:45 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoHAFDtTExAZnwM/2dsb2JhbACTGYxHcaQxmg2DCIIuBIhk X-IronPort-AV: E=Sophos;i="4.55,260,1278288000"; d="scan'208";a="139140615" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2010 09:09:06 +0000 Received: from dhcp-24db.meeting.ietf.org (ams3-vpn-dhcp5503.cisco.com [10.61.85.126]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6Q995Td010859 for ; Mon, 26 Jul 2010 09:09:06 GMT Message-Id: <786202C9-86DE-4567-9C39-24488AB72309@cisco.com> From: Brian Weis To: ipsec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 11:09:05 +0200 X-Mailer: Apple Mail (2.936) Subject: [IPsec] draft-ietf-msec-ipsec-group-counter-modes-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:08:47 -0000 Greetings, This draft was mentioned in the IPSECME session today. It describes a strategy for safely sharing an IPsec SA between multiple senders when the SA includes a block cipher counter mode. It has been suggested that strategy may be useful for cluster members sharing this kind of SA. The draft has officially ended IETF last call, but timely comments are still welcome. Thanks, Brian > The IESG has received a request from the Multicast Security WG (msec) > to > consider the following document: > > - 'Using Counter Modes with Encapsulating Security Payload (ESP) and > Authentication Header (AH) to Protect Group Traffic ' > as a Proposed > Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2010-07-23. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-group- > counter-modes-05.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15718&rfc_flag=0 > -- Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From kivinen@iki.fi Mon Jul 26 05:33:29 2010 Return-Path: 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 113AB3A6AD7 for ; Mon, 26 Jul 2010 05:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] 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 d9V10qgGpSV5 for ; Mon, 26 Jul 2010 05:33:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 681633A6BD9 for ; Mon, 26 Jul 2010 05:32:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o6QCX1PD004469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jul 2010 15:33:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o6QCX1VM011800; Mon, 26 Jul 2010 15:33:01 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19533.32893.177798.273183@fireball.kivinen.iki.fi> Date: Mon, 26 Jul 2010 15:33:01 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <19532.19106.297495.280881@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 22 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 12:33:31 -0000 Yoav Nir writes: > I agree that the draft in its current form glosses over the fact > that the missing IKE exchanges did something, like setting up a > child SA, or tearing one down. I don't believe there is any way you > can set up a cluster so that this never ever happens. You can make > it rare, but not completely eliminate it. It does require bit more implementation effor to make them so that they never happen (but that causes bit more traffic on the sync channel as the active node needs to know whether standby received its sync message before it can send IKEv2 message back). On the other hand there is no reason to completely eliminate that, making it rare is enough (i.e. assume that majority of the sync channel traffic is going through and there is no need to get ack from other end before continuing IKEv2 exchange). > When this does happen, we have two things we might prescribe. We can > detect this and delete the IKE SA along with all associated child > SAs, or we can try to recover. > draft-kagarigi-ipsecme-ikev2-windowsync takes the latter way. draft-kagarigi-ipsecme-ikev2-windowsync does not try to recover, it just skips over the problem. It could provide a way to detect this, i.e. it peers could quickly check the message ids and check whether they missed some IKEv2 messages and if so they could do something (for example delete that IKEv2 SA directly just to clean up state quickly). > To get recovery actually working we need some more "stuff". I think we need quite a lot of more stuff, if we really want to recover fully for those lost messages. > We need to accept this case of mis-matched states between peers, and I would rather not accept the mis-matched state. I would rather clean up those messed up IKE SAs and recreate them to get the state matching than trying to make protocol trying to recover from messed up state. > work towards making them better matched, by allowing an > implementation to inform its peer that the SA that is using is > unknown - an obvious thing is to send an INVALID_SPI notify in an > INFORMATIONAL exchange, That is one option, but I think the draft needs to add text explaining how to handle cases where: 1) Peer did IPsec SA delete, which active member answered, but which got undone when standby member took over. 2) Peer did IPsec SA Create Child SA, which active member answerd, but which got undone when standby member took over. 3) Peer did IPsec SA rekey, which active member answered, but which got undone when standby member took over. 4) Peer did IKEv2 SA rekey, which active member answered, but which got undone when standby member took over. Then exactly same cases where the active member started those negotiations and peer responded, but then change got undone when standby member took over (there are cases where there is difference depending who started operation, for example in the rekey case the initiator is supposed to delete the old SA, so if the crashed active member started that the standby member will not continue that operation even when peer expects that to happen). > or maybe add a DELETE_ALL_CHILDREN > notification. That would be about the same than deleting the IKEv2 SA, except deleting IKEv2 SA also takes care of other configuration data like configuration payload information (virtual addresses etc). I would suggest it would be better to just delete the whole IKEv2 SA than to create another protocol extension to delete all IPsec SAs. > The draft will need text that discusses how this actually converges > in a matched IKE SA. > > It should be noted (in the draft!) that this changes some > assumptions about IKEv2 state. Yes. I would except that going through all those cases and explaining what will happen to them and how they are supposed to work takes several pages (in IKEv2bis we have about 3.5 pages of similar text (simultaneous rekeys and exchange collisions sections)). As that is also going to require implementations I would really hope if this IKEv2 SA window sync part is ever defined it will made optional so it can be left out. -- kivinen@iki.fi From jarrett.lu@oracle.com Wed Jul 28 00:31:09 2010 Return-Path: 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 084D23A68D7 for ; Wed, 28 Jul 2010 00:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 v0CQIfoFm3pk for ; Wed, 28 Jul 2010 00:31:00 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id B92E028C0EE for ; Wed, 28 Jul 2010 00:30:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6S7VIbl006349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 28 Jul 2010 07:31:20 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6S7VGmL017797 for ; Wed, 28 Jul 2010 07:31:16 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 443338041280302211; Wed, 28 Jul 2010 00:30:11 -0700 Received: from [130.129.48.237] (/130.129.48.237) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jul 2010 00:30:09 -0700 Message-ID: <4C4FDC80.5020603@oracle.com> Date: Wed, 28 Jul 2010 00:30:08 -0700 From: "jarrett.lu@oracle.com" User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.10) Gecko/20100621 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C4FDCC6.010B:SCFMA4539814,ss=1,fgs=0 X-Mailman-Approved-At: Wed, 28 Jul 2010 09:15:12 -0700 Subject: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jarrett.lu@oracle.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 07:31:09 -0000 A new 00 version of IKEv2 extension for security label has just been published: http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 Authors welcome comments from IPsec community. Thanks. - Jarrett From ynir@checkpoint.com Wed Jul 28 09:26:18 2010 Return-Path: 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 C9EE028C0CF for ; Wed, 28 Jul 2010 09:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599] 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 nw4-F6gAeAVQ for ; Wed, 28 Jul 2010 09:26:17 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 80CC228C15E for ; Wed, 28 Jul 2010 09:26:17 -0700 (PDT) X-CheckPoint: {4C5065F3-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o6SGQdDq003720; Wed, 28 Jul 2010 19:26:39 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 28 Jul 2010 19:27:11 +0300 From: Yoav Nir To: "jarrett.lu@oracle.com" Date: Wed, 28 Jul 2010 19:26:37 +0300 Thread-Topic: [IPsec] a new IKEv2 labeled security draft is published Thread-Index: AcsucboCouJRqqvUQMewmZ8gon3HNg== Message-ID: <7F39496A-D7DF-44AF-9922-88D13897A417@checkpoint.com> References: <4C4FDC80.5020603@oracle.com> In-Reply-To: <4C4FDC80.5020603@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 16:26:18 -0000 On Jul 28, 2010, at 9:30 AM, jarrett.lu@oracle.com wrote: > A new 00 version of IKEv2 extension for security label has just been=20 > published: >=20 > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 >=20 > Authors welcome comments from IPsec community. >=20 > Thanks. You will get that, but first, please tell us your plans for this. Would you like to get this published as individuals/independant, or do you = plan to try again to have this accepted into the IPSecME agenda? From jarrett.lu@oracle.com Wed Jul 28 09:37:46 2010 Return-Path: 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 74C543A6A94 for ; Wed, 28 Jul 2010 09:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TPspodfWhuca for ; Wed, 28 Jul 2010 09:37:45 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 48BED3A6969 for ; Wed, 28 Jul 2010 09:37:45 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6SGbxrq003996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jul 2010 16:38:00 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6SFPtVq003253; Wed, 28 Jul 2010 16:37:58 GMT Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 465054031280335077; Wed, 28 Jul 2010 09:37:57 -0700 Received: from [130.129.116.177] (/130.129.116.177) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jul 2010 09:37:56 -0700 Message-ID: <4C505CDE.6050806@oracle.com> Date: Wed, 28 Jul 2010 09:37:50 -0700 From: "jarrett.lu@oracle.com" User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.10) Gecko/20100621 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Yoav Nir References: <4C4FDC80.5020603@oracle.com> <7F39496A-D7DF-44AF-9922-88D13897A417@checkpoint.com> In-Reply-To: <7F39496A-D7DF-44AF-9922-88D13897A417@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C505CE7.00F7:SCFMA4539814,ss=1,fgs=0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jarrett.lu@oracle.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 16:37:46 -0000 On 07/28/10 09:26 AM, Yoav Nir wrote: > On Jul 28, 2010, at 9:30 AM, jarrett.lu@oracle.com wrote: > > >> A new 00 version of IKEv2 extension for security label has just been >> published: >> >> http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 >> >> Authors welcome comments from IPsec community. >> >> Thanks. >> > You will get that, but first, please tell us your plans for this. > > Would you like to get this published as individuals/independant, or do you plan to try again to have this accepted into the IPSecME agenda? > > Sorry I didn't make it clear earlier. It's intended to be an individual submission and will become an experimental RFC. Thanks. Jarrett From dpquigl@tycho.nsa.gov Wed Jul 28 11:11:28 2010 Return-Path: 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 0648E3A6A44 for ; Wed, 28 Jul 2010 11:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 T2sXbwjLCW9M for ; Wed, 28 Jul 2010 11:11:19 -0700 (PDT) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by core3.amsl.com (Postfix) with ESMTP id DD0FF3A6884 for ; Wed, 28 Jul 2010 11:11:04 -0700 (PDT) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o6SIAxha004079; Wed, 28 Jul 2010 18:10:59 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o6SIB23u028297; Wed, 28 Jul 2010 14:11:02 -0400 From: "David P. Quigley" To: Yoav Nir In-Reply-To: <7F39496A-D7DF-44AF-9922-88D13897A417@checkpoint.com> References: <4C4FDC80.5020603@oracle.com> <7F39496A-D7DF-44AF-9922-88D13897A417@checkpoint.com> Content-Type: text/plain Organization: National Security Agency Date: Wed, 28 Jul 2010 13:59:46 -0400 Message-Id: <1280339986.2673.58.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , "jarrett.lu@oracle.com" Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 18:11:28 -0000 On Wed, 2010-07-28 at 19:26 +0300, Yoav Nir wrote: > On Jul 28, 2010, at 9:30 AM, jarrett.lu@oracle.com wrote: > > > A new 00 version of IKEv2 extension for security label has just been > > published: > > > > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 > > > > Authors welcome comments from IPsec community. > > > > Thanks. > > You will get that, but first, please tell us your plans for this. > > Would you like to get this published as individuals/independant, or do you plan to try again to have this accepted into the IPSecME agenda? > As Jarrett mentioned down thread this is not intended to become an IPSecME working group item. I spoke with Paul Hoffman at Anaheim about the correct path forward for this document. He gave us some advice for making the document more easily reviewed (remove ikev1, and SA text). He also said that the best course of action would be an Individual submission on either an Experimental or Informational RFC track. He mentioned that this would require review from the working group and if the working group later decided that the work is baked enough and has enough backing to become a working group item they could move it from an individual submission to an IPSecME working group document. The most important thing at the moment is to get the technology thoroughly reviewed by as many people as possible. This way we can make sure that all of the protocol decisions that we've made are well thought out and are an acceptable way of doing things. Dave From yaronf.ietf@gmail.com Wed Jul 28 13:06:45 2010 Return-Path: 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 CC5E828C179 for ; Wed, 28 Jul 2010 13:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_DIET=2.3] 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 a9RRwcx2I+RD for ; Wed, 28 Jul 2010 13:06:44 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id DBC4F3A687B for ; Wed, 28 Jul 2010 13:06:43 -0700 (PDT) Received: by ewy22 with SMTP id 22so2131070ewy.31 for ; Wed, 28 Jul 2010 13:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=RNRscGEM6Pt6sN3o3ttGc0W5p5m5HNb8vqkZo/tmhg4=; b=m6twrzlhI18PG33aYcFXpDvMLQHxLWoPVPgQ/4gcvanEEbQOr8TTxaAnggB4L+sLB+ AJSCmazg+LxWt7Y+Zw6SdPWc9vX4HLMBSLVrKjAKQiy+CD7/AHN59Zc76N3c24gOVAqX SriaQHzePXhZSxKSNAe6/qcZP4H85SL2UGjsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=mt2iyXgAvOAG+cKBskpr/kW2ua8lxlT9rthQO3O+I53l7Q0JWxxPdBu3kxqabPFDxA 9jSjMPKASmoAaxTY14ca3snU29igVlLPzdbbz2ZscY0UUSu+qF+pYX5FUSAv5xAthYaz n5mLyHzGCx+KYWNZpN4PxLJPfDJoEu7BYcL1c= Received: by 10.213.77.75 with SMTP id f11mr6129590ebk.15.1280347626480; Wed, 28 Jul 2010 13:07:06 -0700 (PDT) Received: from [10.0.0.1] ([109.65.43.240]) by mx.google.com with ESMTPS id a48sm10081446eei.12.2010.07.28.13.07.03 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 13:07:05 -0700 (PDT) Message-ID: <4C508DE4.1080002@gmail.com> Date: Wed, 28 Jul 2010 23:07:00 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [IPsec] Draft minutes of the Maastricht meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 20:06:45 -0000 Below the minutes. Clarifications/corrections are welcome. Thanks to Jim for taking extensive notes during the meeting! Yaron --- IPSECME Meeting Notes Note taker: Jim Schaad. All remaining errors by Paul and Yaron. Agenda bash & Status - IPsec is due to change from MUST to SHOULD in the new IPv6 node requirements doc. - Ongoing discussion on using CGA for authentication, some aspects relevant to IPsec. HA Recap slides People should read McGrew's msec counter mode document, now in IETF last call. [Pointer sent separately on the list.] RFC5297 - Auth encryption mode is another solution (a different block encryption mode). HA Solutions slides Steve Kent - cluster member taking over shoves done and peer response as needed. Paul - Each SA is synced up independently. Steve - Should be indication of knowledge of more SAs to be synced later Raj - "More" flag indicates that more SAs are coming Paul - Nothing about what happens if "more coming" flag is not set Raj - peer can initiate for secondary SAs (?) Dave McGrew - How is a replay attack possible? [offline commentary: ESP replay is in principle equivalent to replication of packets by the network, and thus not an attack; however the draft attempts to preserve existing ESP security guarantees.] Raj - Lost IKE SA so counters can be reused - must fit in IKE window DM - ESP and AH - possible attack here? R - After failover happens can safely stop traffic DM - expand R - Active member sync w/ standby - counter =1700 = now counter is 1800 - standby starts from 1700 (last sync) looks like replay attack to peer Yoav - Sync counters every 1000 must - peer can now resend message 1001 again after failover since does not know that it exists. DM - situation where cluster is not following RFC [each gateway is compliant, but the cluster as a whole is not]. SK - cannot go 100% HA - could toss on floor or accept possibility of replay Yoav - could send one message to skip forward on all IPsec SAs, then peer just jumps forward and can do all SAs at the same time. R - different data traffic on SAs - so possibly different traffic rates Paul - just not full IKEv2 - similar to concept of your other side might have forgotten something and you need to re-sync - not currently specified. Tero – there is a real replay attack remaining, rate limiting does not help at all - replay counters where set back anyway - peer should know better as window is not matching well. This is my counter - peer should send my feeling of counters – and then send back larger numbers - change in design. Yaron - Rate limiting does not solve problem - should solve at the transport and message level - not semantics of the payload – one option is to have a “failover counter” that's incremented on failover events. Dan - What is the protection against bad packets from an attacker – can this cause a resync R - Must be preceded by a failover event detection R - addressing rate limit w/ special Message ID 0 Tero - Protocol should be split into two parts - IKE SA and IPsec SA counter syncs - different ideas of how they should be working. Problem IKE SA syncing - assume we missed some message - just need to sync counters - need to look at what those messages are really doing – need all changes to active SAs. Need text to say what happens for each different type of message. Easier to sync the SA counters when they occur. Paul - If two parts of cluster are not sync perfectly - the wrong picture on the failover server coming up. Risk is high and better to do a full re-key when states are wrong. Tero - don't need message id 0, just a normal IKE message and continue. R - Not possible to send a normal IKE message because of out of window T - Want to kill IKE SA if out of window. If two are out of sync - fall-back comes up - normal message ids - everything but a couple are out of sync - those few can be re-built from scratch. Yaron - quantitative question - DPD wants to happen a lot in some cases -IKE brittleness [dependence on exact counter sync] will be a problem and go out of sync - could be a high percentage of SAs out of sync. If only for real traffic that causes a sync failure - then maybe don't need all of this work. Paul - ? - cluster member knows what type of syncing is occurring – if Tero style SA [few DPDs] then don't need to do this type of work. Based on the type of message then this is needed? Yaron - Yes - Paul - could make this a runtime situation decision. Tero - Why would you want to send lots of DPD message? - If no reason to be doing this then changes the issue for this document. Paul - Not relevant - cluster member has lots of things to look out. Tero - Protocol is useful if IKE messages much more frequently than sync messages. Otherwise this is not useful. Paul - Cluster member should have a feeling [re: traffic rates and composition]. Tero - no just the IKE part is not needed. Paul - missed that - in splitting the IKE part can be removed Yaron - DPD issue is not a morality question - protocol allows for them, they will be aggressively used and thus we need to deal with this issue. Paul – aggressive DPD seen “in the wild” in existing products R - different peers can be sending DPDs as well. - including clients - this is a cluster - other messages that occur - could miss a rekey early than needed? Tero - no that does not help - R - arguing why IKEv2 part is needed - enables DPD - childless SA - rekey may occur earlier and then try Paul - sense of the room - who read it - 10 people Splitting request - how many people think this makes sense - more people think spiting makes sense. Let's hold on the kill of IKEv2 until after the split discussion is finished. Tero - Does not solve all security problems - IKE part - sends biggest message id sent - forgets everything in the current window - sends biggest replay to date. R - protocol does not say ignore all message T - doc says forget all message R - allows for rekey questions Yaron – security should not depend on higher level semantics - need to not allow for replay of messages - could make it a multiple (3 or 4) message exchange T - does not clarify what is going on - Peer thinks an on-going is processing and could get the replay prior to an SA response coming back (via different and slower routing) P - Please send to list - assume split occurs and send multiple sets. Yaron - separate security infrastructure Brian Weis - Solving replay problem is extremely important - w/ nonces will be requirement - how much do we save over the rekey if we go to multiple messages? - different between child SAs and IKE Yaron - if splitting then the multiple message game is just for the IKE SA part T - IPsec SA syncing part. - why we need to the maximum. - goes away if message id 0 goes away - currently document says - when failure sends out counters - says this is the biggest counter I have seen to-date - Peer sends back to and may have a lower counter and thus replay back to the peer. R - not to have a crash counter because one more state is required to have and must be maintained by the peer as well as the cluster. T - solving replay is more important than making the optimization in the peer. P - design team has over optimized - may need to be removed T - Text saying counters are incremented [should say, “incremented by a large number”] P - wording issues T - if not large enough number incremented - then peer knows it is higher - thus a replay window has been opened. P - Section 8 needs to be re-written. Was surprised by some of the text in section 8 on first read Yaron - questions -= In favor of making it a working group draft - some hums no one against Failure Detection Decision Process Raj - If we can detect the crash and do retransmissions - most of the job is in the gateways - crash detection can be important - offloads some work to the client or peer - helps load balancing w/ loose clusters – see applicability of this. Paul - do you see this valuable for which end of the cluster R - see value in both sides of the connection T - quick crash recovery is desired - but good implementations can do this - don't need protocol support for this - QCD does offer something - but SIR offers nothing. Don't agree same MITM attack level in SIR as in normal IKE. Looking at slide 4 - none of these proposals addresses the second bullet item. Bob does not know anything about Alice anymore. Yoav - QCD and SIR have been in draft form for 3 years- The idea of “birth certificates” was mentioned ten years ago on the list but never materialized as a document. Crashing on clusters is not as big of an issue. Could be an issue for single gateways however. R - Different types of clusters - load balance can be an issue as well. Yoav - w/ IKEv1 we could solve this in the protocol - setup the delete message and stored it on disk. could then pull up message and send the delete messages when things looked weird. Would be needed because people are trying to do it. Basil- QCD would be better Yaron - does this imply it is needed Basil - yes I think so - cannot be addressed simply - Paul - short round on the list - but crash detection effort will probably die w/o much support showing up. SEED in IPsec [short presentation on the new document]. Labeled IPsec - Jarrett Lu - new document will now be published. Paul - Please let us know at the start and the finish of this type of work so that we can do some review - but the discussion is not on the mailing list. PAKE - Sean Turner Will go forward with PAKE as IETF stream Experimental [possibly multiple different solutions]. Will push as it comes up Dan: - willing to start screaming bloody murder now [over the decision to drop PAKE from the working group] This working group is generically quiet - three different reactions to different documents EAP only got no comments - and is moving forward Liveness [crash detection] - concerted decision to cheer-lead PAKE - lack of reaction except from author - caused work item to be eliminated Three outcomes from basically same response of the working group Paul - did cheer-lead for PAKE as well. will end up with similar results - correct on pushing some with too little discussion out the door – now considered a mistake. Sean - some may be naivety on my part - newness on the IESG. Paul - think PAKE is much bigger than the EAP mutual Tero - biggest PAKE problem is that most people not able to select between the different docs - need to have a single document to choose. Force the authors to pick. Paul - good response [by the authors] on the list - best response except for asking some to die. T - see if there is now a common single document that the authors can agree on. Think authors are currently the best ones to do the selection Paul - will see if this can work Yaron - think if one proposal can have more support? Paul - Question if have a single PAKE - will you spend more time on this document? 3 new people. Radia - Do we understand the IPR situation? Suspect that is some of the disinterest in this topic. Dave - tend to use strong secrets for authentication [in storage applications] - understand that may be stronger derived from weaker - will look at a single draft. Radia - Might be a good idea given the EKE patent might expire soon - that this might be the best way. Yaron - what if the authors say it is good [as far as IPR] Radia - not good enough unless some type of legal protection involved. Yoav - failure of the working group system if the WG cannot decide between different proposals. WG is no longer bringing value into the process. Paul - Does not mean anything on the experimental vs standards tagging. Imachin (?) - PAKE author - Think it might be better for the authors to present proposals at the next IETF. Paul - tired of wasting time and we have done that in the past and it did not seem to move forward. Yoav - how do we avoid this situation for the QCD vs SIR vs the virtual birth certs ??? From paul.hoffman@vpnc.org Fri Jul 30 02:08:53 2010 Return-Path: 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 B51F528C2BA for ; Fri, 30 Jul 2010 02:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.823 X-Spam-Level: X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=1.223, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 JM0suEmrB4IG for ; Fri, 30 Jul 2010 02:08:52 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D634728C2BC for ; Fri, 30 Jul 2010 02:08:52 -0700 (PDT) Received: from [130.129.98.251] (dhcp-62fb.meeting.ietf.org [130.129.98.251]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6U99EXY093798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jul 2010 02:09:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 30 Jul 2010 11:09:12 +0200 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Fwd: I-D Action:draft-kagarigi-ipsecme-ikev2-windowsync-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 09:08:53 -0000 This is the same draft as was temporarily published on the WG's wiki. Everyone should be reading this and discussing it on the list. --Paul Hoffman >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IKEv2/IPsec SA counter synchronization > Author(s) : K. Garigipati > Filename : draft-kagarigi-ipsecme-ikev2-windowsync-04.txt > Pages : 14 > Date : 2010-07-29 > >IKEv2 and IPsec protocols are widely used for deploying VPN. In >order to make such VPN highly available and failure-prone, these VPNs >are implemented as IKEv2/IPsec Highly Available (HA) cluster. But >there are many issues in IKEv2/IPsec HA cluster. The draft "IPsec >Cluster Problem Statement" enumerates all the issues encountered in >IKEv2/IPsec HA cluster environment. > >This draft proposes an extension to IKEv2 protocol to solve main >issues of "IPsec Cluster Problem Statement" in Hot Standby cluster >and gives implementation advice for others. The main issues to be >solved are: >o IKE Message Id synchronization : This is done by obtaining the > >message Id values from the peer and updating the values at the > >newly active cluster member after the failover. >o IPsec SA Counter synchronization : This is done by sending > >incremented the values of replay counters by the newly active > >cluster member to the peer as expected replay counter value. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kagarigi-ipsecme-ikev2-windowsync-04.txt From paul.moore@hp.com Fri Jul 30 13:49:24 2010 Return-Path: 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 AAB9F3A6B0F for ; Fri, 30 Jul 2010 13:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 GLOABampYFci for ; Fri, 30 Jul 2010 13:49:22 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by core3.amsl.com (Postfix) with ESMTP id 7057B3A699A for ; Fri, 30 Jul 2010 13:49:20 -0700 (PDT) Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141]) by g5t0006.atlanta.hp.com (Postfix) with ESMTP id B80C5C40A; Fri, 30 Jul 2010 20:49:44 +0000 (UTC) Received: from ldl (ldl.fc.hp.com [15.11.146.30]) by g5t0029.atlanta.hp.com (Postfix) with ESMTP id A1BF1200F0; Fri, 30 Jul 2010 20:49:44 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 672BDCF0018; Fri, 30 Jul 2010 14:49:44 -0600 (MDT) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT6tGCLjb5JF; Fri, 30 Jul 2010 14:49:44 -0600 (MDT) Received: from [192.168.0.130] (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id DCDD1CF000E; Fri, 30 Jul 2010 14:49:43 -0600 (MDT) From: Paul Moore To: jarrett.lu@oracle.com In-Reply-To: <4C4FDC80.5020603@oracle.com> References: <4C4FDC80.5020603@oracle.com> Content-Type: text/plain; charset="us-ascii" Organization: Hewlett-Packard Date: Fri, 30 Jul 2010 16:49:42 -0400 Message-ID: <1280522982.4029.24.camel@flek.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 20:49:24 -0000 On Wed, 2010-07-28 at 00:30 -0700, jarrett.lu@oracle.com wrote: > A new 00 version of IKEv2 extension for security label has just been > published: > > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 > > Authors welcome comments from IPsec community. Having just read the draft I think it is a bit difficult to perform any in-depth review without the LFS document (which is described as a work in progress); there just isn't any real substance in this draft in my opinion. That said, I did notice two things while reading the draft: * Beyond some grammatical issues in the Introduction, it is probably better to say that SELinux implements a Flask security architecture rather than just type enforcement[1]. -> http://www.cs.utah.edu/flux/fluke/html/te.html * There appears to be a stray line referencing RFC 4301 in the References section at the end of the draft. -- paul moore linux @ hp