From ynir@checkpoint.com Mon Jan 3 07:49:45 2011 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 5BDE33A69E8 for ; Mon, 3 Jan 2011 07:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.876 X-Spam-Level: X-Spam-Status: No, score=-9.876 tagged_above=-999 required=5 tests=[AWL=0.723, 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 FLrqxncWF29k for ; Mon, 3 Jan 2011 07:49:44 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 00E3B3A69E3 for ; Mon, 3 Jan 2011 07:49:40 -0800 (PST) X-CheckPoint: {4D21F093-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p03FplAL020136 for ; Mon, 3 Jan 2011 17:51:47 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 3 Jan 2011 17:51:47 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Mon, 3 Jan 2011 17:51:45 +0200 Thread-Topic: [IPsec] Failure Detection - Issue #200 Thread-Index: AcurXh/6eConFlLYQEOuTtk1fPYnRw== Message-ID: References: <4482BE0E-93AF-44B0-A4DF-302994312D31@checkpoint.com> In-Reply-To: <4482BE0E-93AF-44B0-A4DF-302994312D31@checkpoint.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 Subject: Re: [IPsec] Failure Detection - Issue #200 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, 03 Jan 2011 15:49:45 -0000 Reminder... On Dec 26, 2010, at 11:38 AM, Yoav Nir wrote: > Hi all.=20 >=20 > Issue #200 is about some text in section 8 ("Interaction with Session Res= umption"). The text says that a rebooted peer (and thus a defunct SA) may g= o undetected for the lifetime of the SA. However, RFC 5996 says that at som= e point, a peer that did not receive incoming traffic on a particular IKE S= A or its children, has to initiate a liveness check. >=20 > Here's how I propose to resolve this. Seeing as it's the holiday season,= I won't close the issue until January 10th, but please get your comments i= n by then. >=20 > Existing text: > What Session Resumption does not help is the problem of detecting > that the peer gateway has failed. A failed gateway may go undetected > for as long as the lifetime of a child SA, because IPsec does not > have packet acknowledgement, and applications cannot signal the IPsec > layer that the tunnel "does not work". Before establishing a new IKE > SA using Session Resumption, a client should ascertain that the > gateway has indeed failed. This could be done using either a > liveness check (as in RFC 5996) or using the QCD tokens described in > this document. >=20 > My proposed text: > What Session Resumption does not help is the problem of detecting > that the peer gateway has failed. A failed gateway may go undetected > for an arbitrarily long time, because IPsec does not have packet > acknowledgement, and applications cannot signal the IPsec layer that > the tunnel "does not work". Section 2.4 of RFC 5996 does not specify > how long an implementation needs to wait before beginning a liveness > check, and only says "not recently" (see full quote in Section 2). > In practice some mobile devices wait a very long time before > beginning liveness check, in order to extend battery life by allowing > parts of the device to remain in low-power modes. >=20 > QCD tokens provide a way to detect the failure of the peer in the > case where liveness check has not yet ended (or begun). From smoonen@us.ibm.com Tue Jan 4 07:43:28 2011 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 97E773A6CAA; Tue, 4 Jan 2011 07:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.746 X-Spam-Level: X-Spam-Status: No, score=-3.746 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 rqlXe-bfBAn7; Tue, 4 Jan 2011 07:43:27 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 0B6023A6CA9; Tue, 4 Jan 2011 07:43:26 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p04FeRMD001587; Tue, 4 Jan 2011 08:40:27 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p04FjEAU249582; Tue, 4 Jan 2011 08:45:15 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p04FjEiT001781; Tue, 4 Jan 2011 08:45:14 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p04FjEWI001776; Tue, 4 Jan 2011 08:45:14 -0700 In-Reply-To: References: <4482BE0E-93AF-44B0-A4DF-302994312D31@checkpoint.com> X-KeepSent: 1971B1D7:1AEA856A-8525780E:0054F363; type=4; name=$KeepSent To: Yoav Nir X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Tue, 4 Jan 2011 10:43:38 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/04/2011 08:45:13 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF29DDFC775F38f9e8a93df938690918c0ABBF29DDFC775F3" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Failure Detection - Issue #200 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, 04 Jan 2011 15:43:28 -0000 --0__=0ABBF29DDFC775F38f9e8a93df938690918c0ABBF29DDFC775F3 Content-type: multipart/alternative; Boundary="1__=0ABBF29DDFC775F38f9e8a93df938690918c0ABBF29DDFC775F3" --1__=0ABBF29DDFC775F38f9e8a93df938690918c0ABBF29DDFC775F3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Yoav, I am ok with your suggested change. Side comment: in my reading of RFC 5996 I think we could still say "as = long as the lifetime of a child SA." I read the RFC as requiring liveness checking only in the case where we have sent but not received traffic. = (In other words, I think the sentences "If there has only been ..." and "If= no cryptographically protected ..." are related, with the second being subordinate to the first.) Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir To: "ipsec@ietf.org" Date: 01/03/2011 10:52 AM Subject: Re: [IPsec] Failure Detection - Issue #200 Sent by: ipsec-bounces@ietf.org Reminder... On Dec 26, 2010, at 11:38 AM, Yoav Nir wrote: > Hi all. > > Issue #200 is about some text in section 8 ("Interaction with Session= Resumption"). The text says that a rebooted peer (and thus a defunct SA= ) may go undetected for the lifetime of the SA. However, RFC 5996 says th= at at some point, a peer that did not receive incoming traffic on a partic= ular IKE SA or its children, has to initiate a liveness check. > > Here's how I propose to resolve this. Seeing as it's the holiday sea= son, I won't close the issue until January 10th, but please get your comment= s in by then. > > Existing text: > What Session Resumption does not help is the problem of detecting > that the peer gateway has failed. A failed gateway may go undetect= ed > for as long as the lifetime of a child SA, because IPsec does not > have packet acknowledgement, and applications cannot signal the IPs= ec > layer that the tunnel "does not work". Before establishing a new I= KE > SA using Session Resumption, a client should ascertain that the > gateway has indeed failed. This could be done using either a > liveness check (as in RFC 5996) or using the QCD tokens described i= n > this document. > > My proposed text: > What Session Resumption does not help is the problem of detecting > that the peer gateway has failed. A failed gateway may go undetect= ed > for an arbitrarily long time, because IPsec does not have packet > acknowledgement, and applications cannot signal the IPsec layer tha= t > the tunnel "does not work". Section 2.4 of RFC 5996 does not speci= fy > how long an implementation needs to wait before beginning a livenes= s > check, and only says "not recently" (see full quote in Section 2). > In practice some mobile devices wait a very long time before > beginning liveness check, in order to extend battery life by allowi= ng > parts of the device to remain in low-power modes. > > QCD tokens provide a way to detect the failure of the peer in the > case where liveness check has not yet ended (or begun). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBF29DDFC775F38f9e8a93df938690918c0ABBF29DDFC775F3 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Yoav, I am ok with your suggested change.

Side comment: in my reading of RFC 5996 I think we could still say &quo= t;as long as the lifetime of a child SA." I read the RFC as requi= ring liveness checking only in the case where we have sent but not rece= ived traffic. (In other words, I think the sentences "If there ha= s only been ..." and "If no cryptographically protected ...&q= uot; are related, with the second being subordinate to the first.)


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveYoav Nir ---01/03/2011 10:5= 2:15 AM---Reminder... On Dec 26, 2010, at 11:38 AM, Yoav Nir wrote:

From: Yoav N= ir <ynir@checkpoint.com>
To: "ip= sec@ietf.org" <ipsec@ietf.org>
Date: 01/03/= 2011 10:52 AM
Subject: Re:= [IPsec] Failure Detection - Issue #200
Sent by: ips= ec-bounces@ietf.org




Reminder...

On Dec 26, 2010, at 11:38 AM, Yoav Nir wrote:

> Hi all.
>
> Issue #200 is about some text in section 8 ("Interaction with= Session Resumption"). The text says that a rebooted peer (and thu= s a defunct SA) may go undetected for the lifetime of the SA. However, = RFC 5996 says that at some point, a peer that did not receive incoming = traffic on a particular IKE SA or its children, has to initiate a liven= ess check.
>
> Here's how I propose to resolve this.  Seeing as it's the hol= iday season, I won't close the issue until January 10th, but please get= your comments in by then.
>
> Existing text:
>   What Session Resumption does not help is the problem of det= ecting
>   that the peer gateway has failed.  A failed gateway ma= y go undetected
>   for as long as the lifetime of a child SA, because IPsec do= es not
>   have packet acknowledgement, and applications cannot signal= the IPsec
>   layer that the tunnel "does not work".  Befo= re establishing a new IKE
>   SA using Session Resumption, a client should ascertain that= the
>   gateway has indeed failed.  This could be done using e= ither a
>   liveness check (as in RFC 5996) or using the QCD tokens des= cribed in
>   this document.
>
> My proposed text:
>   What Session Resumption does not help is the problem of det= ecting
>   that the peer gateway has failed.  A failed gateway ma= y go undetected
>   for an arbitrarily long time, because IPsec does not have p= acket
>   acknowledgement, and applications cannot signal the IPsec l= ayer that
>   the tunnel "does not work".  Section 2.4 of = RFC 5996 does not specify
>   how long an implementation needs to wait before beginning a= liveness
>   check, and only says "not recently" (see full quo= te in Section 2).
>   In practice some mobile devices wait a very long time befor= e
>   beginning liveness check, in order to extend battery life b= y allowing
>   parts of the device to remain in low-power modes.
>
>   QCD tokens provide a way to detect the failure of the peer = in the
>   case where liveness check has not yet ended (or begun).
=
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBF29DDFC775F38f9e8a93df938690918c0ABBF29DDFC775F3-- --0__=0ABBF29DDFC775F38f9e8a93df938690918c0ABBF29DDFC775F3 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF29DDFC775F38f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF29DDFC775F38f9e8a93df938690918c0ABBF29DDFC775F3-- From paul.hoffman@vpnc.org Tue Jan 4 17:13:16 2011 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 0652E3A679C for ; Tue, 4 Jan 2011 17:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.64 X-Spam-Level: X-Spam-Status: No, score=-101.64 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 SNMvizwsobVp for ; Tue, 4 Jan 2011 17:13:15 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 303C03A66B4 for ; Tue, 4 Jan 2011 17:13:15 -0800 (PST) Received: from MacBook-08.local (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 p051FLHC092879 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 4 Jan 2011 18:15:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D23C629.3040306@vpnc.org> Date: Tue, 04 Jan 2011 17:15:21 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Proposed virtual interim WG January 25 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, 05 Jan 2011 01:13:16 -0000 We propose have a virtual interim WG meeting near the end of this month to discuss any remaining issues with the failure detection document. We propose a conference call on Tuesday January 25, 16:00 GMT (21:30 Kolkata, 18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for up to 2 hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides (if needed). Technical details here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls. Let us know in the next few days if you have any major issues with the time and/or the format. From paul.hoffman@vpnc.org Wed Jan 5 18:58:08 2011 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 711733A6E59 for ; Wed, 5 Jan 2011 18:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.922 X-Spam-Level: X-Spam-Status: No, score=-100.922 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, 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 8kr7eiRUYzao for ; Wed, 5 Jan 2011 18:58:07 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CA6203A6E57 for ; Wed, 5 Jan 2011 18:58:07 -0800 (PST) Received: from MacBook-08.local (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 p06305PH048213 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 5 Jan 2011 20:00:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D253035.3060204@vpnc.org> Date: Wed, 05 Jan 2011 19:00:05 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipsec@ietf.org References: <4482BE0E-93AF-44B0-A4DF-302994312D31@checkpoint.com> In-Reply-To: <4482BE0E-93AF-44B0-A4DF-302994312D31@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yoav Nir Subject: Re: [IPsec] Failure Detection - Issue #200 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, 06 Jan 2011 02:58:08 -0000 I am closing this open issue. Yaron: please use your proposed text. Failure detection authors: please have a new draft ready by Monday and close out all the resolved issues on the issue tracker. I think we are getting ready for a WG Last Call. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Fri Jan 7 08:51:04 2011 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 3A6C83A691C; Fri, 7 Jan 2011 08:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.679 X-Spam-Level: X-Spam-Status: No, score=-101.679 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 T06WdNXvJG8H; Fri, 7 Jan 2011 08:51:03 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 842E73A68D0; Fri, 7 Jan 2011 08:51:03 -0800 (PST) Received: from MacBook-08.local (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 p07Gr9GK035692 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 7 Jan 2011 09:53:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D2744F5.3090205@vpnc.org> Date: Fri, 07 Jan 2011 08:53:09 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPsecme WG References: <4D23C629.3040306@vpnc.org> <4D254266.4070804@ieca.com> In-Reply-To: <4D254266.4070804@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg-secretary@ietf.org Subject: Re: [IPsec] Proposed virtual interim WG January 25 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, 07 Jan 2011 16:51:04 -0000 The IPsecME WG will have a virtual interim WG meeting on Tuesday January 25, 16:00 GMT (21:30 Kolkata, 18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for up to 2 hours. The agenda is to discuss any remaining issues with draft-ietf-ipsecme-failure-detection. The meeting will be held as a conference call using a VoIP conference bridge and posted slides (if needed). Technical details here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls. --Paul Hoffman, Director --VPN Consortium From wwwrun@core3.amsl.com Fri Jan 7 12:18:41 2011 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6CF563A6962; Fri, 7 Jan 2011 12:18:41 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110107201841.6CF563A6962@core3.amsl.com> Date: Fri, 7 Jan 2011 12:18:41 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] IPSECME WG Virtual Interim Meeting, January 25, 2010 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, 07 Jan 2011 20:18:41 -0000 The IPsecME WG will have a virtual interim WG meeting on Tuesday January 25, 16:00 GMT (21:30 Kolkata, 18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for up to 2 hours. The agenda is to discuss any remaining issues with draft-ietf-ipsecme-failure-detection. The meeting will be held as a conference call using a VoIP conference bridge and posted slides (if needed). Technical details here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls. From Internet-Drafts@ietf.org Sun Jan 9 23:45:04 2011 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 8F5C228C0EF; Sun, 9 Jan 2011 23:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, 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 somTNGKUgqTN; Sun, 9 Jan 2011 23:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D7A28C0E4; Sun, 9 Jan 2011 23:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110074502.22466.22300.idtracker@localhost> Date: Sun, 09 Jan 2011 23:45:02 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.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, 10 Jan 2011 07:45:04 -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 : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-03.txt Pages : 23 Date : 2011-01-09 This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-failure-detection-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-09234005.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Mon Jan 10 00:01:34 2011 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 72EFD28C0DF for ; Mon, 10 Jan 2011 00:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=0.682, 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 dEeiPaUF3hgM for ; Mon, 10 Jan 2011 00:01:33 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 554EC28C0D9 for ; Mon, 10 Jan 2011 00:01:33 -0800 (PST) X-CheckPoint: {4D2ABD61-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0A834IZ022514 for ; Mon, 10 Jan 2011 10:03:45 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 10 Jan 2011 10:03:15 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Mon, 10 Jan 2011 10:03:15 +0200 Thread-Topic: Issue #202: Token makers generating the same tokens without synchronized DB Thread-Index: AcuwnNU2DeUYQT7YSc+chV9E7CdKBw== Message-ID: References: <20110110074502.22466.22300.idtracker@localhost> In-Reply-To: <20110110074502.22466.22300.idtracker@localhost> 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] Issue #202: Token makers generating the same tokens without synchronized DB 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, 10 Jan 2011 08:01:34 -0000 Greetings. We have just submitted version -03 of the draft. This closes issues, #198,= #199, #200, and #201. Which leaves us with just one issue: #202 =3D=3D=3D=3D=3D=3D=3D=3D=3D Issue #202: Token makers generating the same to= kens without synchronized DB Section 10.4 of the draft has a use-case where a cluster of gateways share = the same QCD token secret, because they back each other up. The twist in this case, is that they don't have synchronized databases, so = a fail-over is very much like a reboot - the IKE SA is gone, and QCD is eff= ective in getting the other side to restart IKE quickly. The problem is, that without a failover, it may be possible to get a member= that does not own the IKE SA to send the QCD token to an attacker. The att= acker can then use this QCD token to tear down the IKE SA. The method in section 5.2 tries to address this, by considering the IP addr= ess of the token taker in the calculation. Tero claims that this is a scenario that we should not address, and that pr= edicting or prescribing load balancer behavior in inherently dangerous. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please send your opinions to the list. This one actually addresses the scop= e of the document, so it's strange that this comes up as the last issue, bu= t we still have to decide on this. Yoav From gpoothia@microsoft.com Mon Jan 10 14:19:21 2011 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 F1C113A63C9 for ; Mon, 10 Jan 2011 14:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4znashyRfySz for ; Mon, 10 Jan 2011 14:19:17 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 3A2823A63CA for ; Mon, 10 Jan 2011 14:19:17 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 Jan 2011 14:21:31 -0800 Received: from TK5EX14MBXC118.redmond.corp.microsoft.com ([169.254.9.92]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Mon, 10 Jan 2011 14:21:31 -0800 From: Gaurav Poothia To: "ipsec@ietf.org" Thread-Topic: Question about TS construction on IKEv2 initiator Thread-Index: AcuxFLq/Ri5WB3/gR6mu963YIt/3rA== Date: Mon, 10 Jan 2011 22:21:30 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_B69601AD18064F4BBA2D61CA82AEAFA9281EF444TK5EX14MBXC118r_" MIME-Version: 1.0 Cc: Brian Swander , Gabriel Montenegro Subject: [IPsec] Question about TS construction on IKEv2 initiator 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, 10 Jan 2011 22:19:21 -0000 --_000_B69601AD18064F4BBA2D61CA82AEAFA9281EF444TK5EX14MBXC118r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Excerpt from RFC 5996 Sec 2.9 "To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request." I am not sure if there is a RFC dictated upper bound on the number of Traff= ic Selectors in each of TSi and TSr. Looking at the examples in the RFC you can surely have 1 or 2 selectors. B= ut are any more allowed? The answer obviously effects the complexity of the responder's TS narrowing= algo where a union of the incoming Traffic Selectors is an input. Thanks --_000_B69601AD18064F4BBA2D61CA82AEAFA9281EF444TK5EX14MBXC118r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Excerpt from RFC 5996 Sec 2.9

“To enable the responder to choose the appropr= iate range in this case,

   if the initiator has requested the SA d= ue to a data packet, the

   initiator SHOULD include as the first T= raffic Selector in each of TSi

   and TSr a very specific Traffic Selecto= r including the addresses in

   the packet triggering the request.̶= 1;

 

I am not sure if there is a RFC dictated upper bound= on the number of Traffic Selectors in each of TSi and TSr.

Looking at the examples in the RFC you can surely ha= ve 1 or 2 selectors.  But are any more allowed?

 

The answer obviously effects the complexity of the r= esponder’s TS narrowing algo where a union of the incoming Traffic Se= lectors is an input.

 

Thanks

 

 

--_000_B69601AD18064F4BBA2D61CA82AEAFA9281EF444TK5EX14MBXC118r_-- From ynir@checkpoint.com Mon Jan 10 15:25:49 2011 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 2E7BE3A67F4 for ; Mon, 10 Jan 2011 15:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VYAF2VGZZlyf for ; Mon, 10 Jan 2011 15:25:48 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 5A4713A679F for ; Mon, 10 Jan 2011 15:25:47 -0800 (PST) X-CheckPoint: {4D2B9601-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0ANS0DQ011549; Tue, 11 Jan 2011 01:28:00 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 11 Jan 2011 01:28:00 +0200 From: Yoav Nir To: Gaurav Poothia Date: Tue, 11 Jan 2011 01:27:59 +0200 Thread-Topic: [IPsec] Question about TS construction on IKEv2 initiator Thread-Index: AcuxHgT/IBi6Z9GGTxGYRLsSnI22ZA== Message-ID: <042F8512-F1F5-42ED-942E-45873BE045B0@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_042F8512F1F542ED942E45873BE045B0checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Brian Swander , Gabriel Montenegro Subject: Re: [IPsec] Question about TS construction on IKEv2 initiator 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, 10 Jan 2011 23:25:49 -0000 --_000_042F8512F1F542ED942E45873BE045B0checkpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gaurav There's a 1-octet field called "Number of TSs", so there can be at most 255= traffic selectors for each of initiator and responder. And yes, as many selectors are allowed as you need to describe your policy.= In practice, some implementations can't handle complex policies, and requ= ire SAs to cover entire subnets or single ranges. If your algorithms only h= andles the first two selectors of each kind, I think it will work fine, but= will produce more SAs than policy dictates. On Jan 11, 2011, at 12:21 AM, Gaurav Poothia wrote: Excerpt from RFC 5996 Sec 2.9 =93To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSi and TSr a very specific Traffic Selector including the addresses in the packet triggering the request.=94 I am not sure if there is a RFC dictated upper bound on the number of Traff= ic Selectors in each of TSi and TSr. Looking at the examples in the RFC you can surely have 1 or 2 selectors. B= ut are any more allowed? The answer obviously effects the complexity of the responder=92s TS narrowi= ng algo where a union of the incoming Traffic Selectors is an input. Thanks --_000_042F8512F1F542ED942E45873BE045B0checkpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gaurav

There's a 1-octet field called "Number of TSs= ", so there can be at most 255 traffic selectors for each of initiator and = responder.

And yes, as many selectors are allowed = as you need to describe your policy.  In practice, some implementation= s can't handle complex policies, and require SAs to cover entire subnets or= single ranges. If your algorithms only handles the first two selectors of = each kind, I think it will work fine, but will produce more SAs than policy= dictates.

On Jan 11, 2011, at 12:21 AM, Gaurav Poo= thia wrote:

Excerpt from RFC 5996 Sec 2.9
=93To enabl= e the responder to choose the appropriate range in this case,
&= nbsp;  if the initiator has requested the SA due to a data packet, the=
   initiator SHOULD include as the first Traffic Sel= ector in each of TSi
   and TSr a very specific Traff= ic Selector including the addresses in
   the packet = triggering the request.=94
 
I am not sure if = there is a RFC dictated upper bound on the number of Traffic Selectors in e= ach of TSi and TSr.
Looking at the examples in the RFC you can = surely have 1 or 2 selectors.  But are any more allowed?
<= o:p> 
The answer obviously effects the complexity of the respon= der=92s TS narrowing algo where a union of the incoming Traffic Selectors i= s an input.
 
Thanks
 
 
<ATT00001..txt>

= --_000_042F8512F1F542ED942E45873BE045B0checkpointcom_-- From kaushalshriyan@gmail.com Mon Jan 10 23:10:20 2011 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 8C7073A69C2 for ; Mon, 10 Jan 2011 23:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZnzuU3pVE5Y for ; Mon, 10 Jan 2011 23:10:19 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 411223A69C0 for ; Mon, 10 Jan 2011 23:10:16 -0800 (PST) Received: by yxt33 with SMTP id 33so8822230yxt.31 for ; Mon, 10 Jan 2011 23:12:32 -0800 (PST) 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=cKx25xlk4WAaW8Pfx+UqNq31ioviud2uqDKvefvfBsk=; b=YwZvkdsIRKF3faSW3aaR6JXd3qTjA0BaSkbesilM+dfDn6KBi6d9DbVmpp+G/z106+ xeNB3rO4D7z1A0WOSGZE1st4pWII2NbmkK3oHxanR2lmu9GAKrNYosQO/xiqb60w6buZ o5rRDunvl58zlIHkqWsHS1D/cICjDrfA9TltQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=O+5qwAmXc/nRIf/o8yLTNiw4XnYLV4LA7Fr3hMI/7BByYOGTXi6XNvoWIMlAObvK1t tYla6IZwMtU6CkzUsMVvvwDG67j921diJRislkx+W9aRTXroMK5Y/1zCY/0W1H8pE9fl UA6HTm3Uj8oKtwlTgvLM47bUsJ8iqFs0hKvZA= Received: by 10.90.74.1 with SMTP id w1mr311758aga.97.1294729951916; Mon, 10 Jan 2011 23:12:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.67.12 with HTTP; Mon, 10 Jan 2011 23:12:11 -0800 (PST) From: Kaushal Shriyan Date: Tue, 11 Jan 2011 12:42:11 +0530 Message-ID: To: IPsec@ietf.org Content-Type: multipart/alternative; boundary=001636283570dd33dc04998ccec0 Subject: [IPsec] IPsec on ubuntu linux server 8.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: Tue, 11 Jan 2011 07:12:52 -0000 --001636283570dd33dc04998ccec0 Content-Type: text/plain; charset=ISO-8859-1 Hi, I did add local4.debug /var/log/ipsec.log in /etc/syslog.conf and restarted sysklogd and also restarted ipsec service. There is nothing in ipsec.log. The file is empty Please suggest/guide. Thanks Kaushal --001636283570dd33dc04998ccec0 Content-Type: text/html; charset=ISO-8859-1 Hi,

I did add local4.debug /var/log/ipsec.log in /etc/syslog.conf and restarted sysklogd and also restarted ipsec service.

There is nothing in ipsec.log. The file is empty

Please suggest/guide.

Thanks

Kaushal
--001636283570dd33dc04998ccec0-- From ynir@checkpoint.com Mon Jan 10 23:28:45 2011 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 929903A69C0 for ; Mon, 10 Jan 2011 23:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.985 X-Spam-Level: X-Spam-Status: No, score=-9.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 pPhgsEUr0jpY for ; Mon, 10 Jan 2011 23:28:44 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id F19913A69B8 for ; Mon, 10 Jan 2011 23:28:43 -0800 (PST) X-CheckPoint: {4D2C0733-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0B7UvRT002798; Tue, 11 Jan 2011 09:30:57 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 11 Jan 2011 09:30:57 +0200 From: Yoav Nir To: Kaushal Shriyan Date: Tue, 11 Jan 2011 09:30:57 +0200 Thread-Topic: [IPsec] IPsec on ubuntu linux server 8.04 Thread-Index: AcuxYXyA3bnbtMEiSfyrHMzWf+unNQ== Message-ID: 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: "IPsec@ietf.org" Subject: Re: [IPsec] IPsec on ubuntu linux server 8.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: Tue, 11 Jan 2011 07:28:45 -0000 Hi Kaushal. This mailing list is about the IKE and IPsec protocols, not some particular= implementation. IIRC on Ubuntu you can install either StrongSwan or racoon, with StrongSwan= being the default on recent versions. I suggest you seek support either at the StrongSwan site ( http://www.stron= gswan.org/ ) or at the Ubuntu forums, which are less specific, but tend to = be very friendly. Yoav On Jan 11, 2011, at 9:12 AM, Kaushal Shriyan wrote: > Hi, >=20 > I did add local4.debug /var/log/ipsec.log in /etc/syslog.conf and restart= ed sysklogd and also restarted ipsec service.=20 >=20 > There is nothing in ipsec.log. The file is empty >=20 > Please suggest/guide. >=20 > Thanks >=20 > Kaushal >=20 >=20 > Scanned by Check Point Total Security Gateway.=20 >=20 > From paul.hoffman@vpnc.org Tue Jan 11 07:31:19 2011 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 7C4A23A6A47 for ; Tue, 11 Jan 2011 07:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.771 X-Spam-Level: X-Spam-Status: No, score=-100.771 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, 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 0Qu4hJ7QUiR1 for ; Tue, 11 Jan 2011 07:31:18 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B56C13A6A40 for ; Tue, 11 Jan 2011 07:31:18 -0800 (PST) Received: from MacBook-08.local (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 p0BFXNxS028460 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 08:33:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D2C7843.7070407@vpnc.org> Date: Tue, 11 Jan 2011 07:33:23 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <20110110074502.22466.22300.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB 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, 11 Jan 2011 15:31:19 -0000 On 1/10/11 12:03 AM, Yoav Nir wrote: > Greetings. > > We have just submitted version -03 of the draft. This closes issues, #198, #199, #200, and #201. > > Which leaves us with just one issue: #202 So far, there have been no posts on this thread. I encourage the document authors to weigh in on the topic soon so that others can see whether they want to as well. From wierbows@us.ibm.com Tue Jan 11 09:36:45 2011 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 DA28628C0DC; Tue, 11 Jan 2011 09:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 HaYEFnWcV1yo; Tue, 11 Jan 2011 09:36:44 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 886993A6A6D; Tue, 11 Jan 2011 09:36:44 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0BHF0dL021808; Tue, 11 Jan 2011 12:15:00 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 438574DE803F; Tue, 11 Jan 2011 12:35:59 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0BHcwi82248882; Tue, 11 Jan 2011 12:38:58 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0BHcwpB025189; Tue, 11 Jan 2011 12:38:58 -0500 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0BHcwB9025176; Tue, 11 Jan 2011 12:38:58 -0500 In-Reply-To: References: <20110110074502.22466.22300.idtracker@localhost> X-KeepSent: D2804B47:27EE4BAD-85257815:005D9A8D; type=4; name=$KeepSent To: "ipsec@ietf.org" , ipsec-bounces@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: David Wierbowski Date: Tue, 11 Jan 2011 12:38:56 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 01/11/2011 12:38:57 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER Cc: Yoav Nir Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB 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, 11 Jan 2011 17:36:46 -0000 I agree with Tero that it is unsafe to assume how a load balancer decides to distribute traffic. Since section 9.4 (previously 10.4) is in the Security Considerations section it seems reasonable to me that we'd warn that the algorithms in 5.1 and 5.2 should not be used in cases where load balancing cluster members share the same QCD token and do not share IKE SA state. I don't think this restriction precludes the use of QCD in the hot-standby cluster scenario that Yoav mentioned in his previous append. By definition in a hot-standby cluster only one of the cluster members is active at any one time and it is not doing load balancing with its standby members. In the same append Yoav stated that to achieve scalability with your hot standby-cluster, you implement load sharing. If you add load balancing to your hot standby-cluster then the warning in the previous paragraph applies. In otherwords if you want one of your standby members to be a load balancing target for the active member in the cluster then you need to share the IKE SA state between the active member and the standby member. I'd recommend that the following text from 9.4 be changed: To thwart this possible attack, such configurations should use a method that considers the taker's IP address, such as the method described in Section 5.2. Dave Wierbowski From: Yoav Nir To: "ipsec@ietf.org" Date: 01/10/2011 03:04 AM Subject: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB Sent by: ipsec-bounces@ietf.org Greetings. We have just submitted version -03 of the draft. This closes issues, #198, #199, #200, and #201. Which leaves us with just one issue: #202 ========= Issue #202: Token makers generating the same tokens without synchronized DB Section 10.4 of the draft has a use-case where a cluster of gateways share the same QCD token secret, because they back each other up. The twist in this case, is that they don't have synchronized databases, so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is effective in getting the other side to restart IKE quickly. The problem is, that without a failover, it may be possible to get a member that does not own the IKE SA to send the QCD token to an attacker. The attacker can then use this QCD token to tear down the IKE SA. The method in section 5.2 tries to address this, by considering the IP address of the token taker in the calculation. Tero claims that this is a scenario that we should not address, and that predicting or prescribing load balancer behavior in inherently dangerous. ======================= Please send your opinions to the list. This one actually addresses the scope of the document, so it's strange that this comes up as the last issue, but we still have to decide on this. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Wed Jan 12 09:51:29 2011 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 836E33A69B7 for ; Wed, 12 Jan 2011 09:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.769 X-Spam-Level: X-Spam-Status: No, score=-100.769 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, 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 DDBTrK5FVXw3 for ; Wed, 12 Jan 2011 09:51:27 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E882D3A6A6D for ; Wed, 12 Jan 2011 09:51:26 -0800 (PST) Received: from MacBook-08.local (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 p0CHrkE1096065 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 12 Jan 2011 10:53:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D2DEAA9.2050301@vpnc.org> Date: Wed, 12 Jan 2011 09:53:45 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection 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, 12 Jan 2011 17:51:29 -0000 Greetings again. This starts the two-week WG Last Call on draft-ietf-ipsecme-failure-detection, currently the -03 draft. There has been very little comment on this document lately, but please not that issue #202 (see ) is still open. Also note that our virtual interim meeting, which is meant to focus on this document, happens the day before this WG LC closes. If there continues to be little comment on the document or on issue #202, that will be a very short meeting. --Paul Hoffman, Director --VPN Consortium From welterk@us.ibm.com Wed Jan 12 12:29:58 2011 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 EF41D3A6A96 for ; Wed, 12 Jan 2011 12:29:57 -0800 (PST) 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, HTML_MESSAGE=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 tTL5jnGRb4Lg for ; Wed, 12 Jan 2011 12:29:57 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 064C33A6A93 for ; Wed, 12 Jan 2011 12:29:56 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0CKDIBY020505 for ; Wed, 12 Jan 2011 15:13:18 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 2E16A4DE803F for ; Wed, 12 Jan 2011 15:29:05 -0500 (EST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0CKW8dg478856 for ; Wed, 12 Jan 2011 15:32:08 -0500 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 p0CKW8JF001163 for ; Wed, 12 Jan 2011 13:32:08 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0CKW834001157 for ; Wed, 12 Jan 2011 13:32:08 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 83382F06:D21E6F23-88257816:0070A15A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Wed, 12 Jan 2011 12:32:07 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/12/2011 13:32:08, Serialize complete at 01/12/2011 13:32:08 Content-Type: multipart/alternative; boundary="=_alternative 0070CE5988257816_=" X-Content-Scanned: Fidelis XPS MAILER Subject: [IPsec] draft-welter-ipsecme-ikev2-reauth-01 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, 12 Jan 2011 20:29:58 -0000 This is a multipart message in MIME format. --=_alternative 0070CE5988257816_= Content-Type: text/plain; charset="US-ASCII" A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has been successfully submitted by Keith Welter and posted to the IETF repository. Filename: draft-welter-ipsecme-ikev2-reauth Revision: 01 Title: Reauthentication Extension for IKEv2 Creation_date: 2011-01-12 WG ID: Independent Submission Number_of_pages: 6 Abstract: This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be reauthenticated without creating a new IKE SA or new Child SAs. The IETF Secretariat. --=_alternative 0070CE5988257816_= Content-Type: text/html; charset="US-ASCII"
A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has been successfully submitted by Keith Welter and posted to the IETF repository.

Filename:                  draft-welter-ipsecme-ikev2-reauth
Revision:                  01
Title:                                   Reauthentication Extension for IKEv2
Creation_date:                  2011-01-12
WG ID:                                   Independent Submission
Number_of_pages: 6

Abstract:
This document describes an extension to the Internet Key Exchange
version 2 (IKEv2) protocol that allows an IKEv2 Security Association
(SA) to be reauthenticated without creating a new IKE SA or new Child
SAs.
                                                                                 


The IETF Secretariat.
--=_alternative 0070CE5988257816_=-- From smoonen@us.ibm.com Wed Jan 12 12:43:50 2011 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 623AB3A69A4 for ; Wed, 12 Jan 2011 12:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 ZnKjCN356BBL for ; Wed, 12 Jan 2011 12:43:48 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 29BC83A67E7 for ; Wed, 12 Jan 2011 12:43:48 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0CKa8Tc020732 for ; Wed, 12 Jan 2011 13:36:08 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p0CKk4U8239036 for ; Wed, 12 Jan 2011 13:46:04 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0CKoVDj021678 for ; Wed, 12 Jan 2011 13:50:31 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0CKoU4A021673 for ; Wed, 12 Jan 2011 13:50:30 -0700 In-Reply-To: <20110110074502.22466.22300.idtracker@localhost> References: <20110110074502.22466.22300.idtracker@localhost> X-KeepSent: A8BE8798:B3640724-85257816:0065945B; type=4; name=$KeepSent To: ipsec@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Wed, 12 Jan 2011 15:45:15 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/12/2011 13:46:03 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF285DFF612CB8f9e8a93df938690918c0ABBF285DFF612CB" Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.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: Wed, 12 Jan 2011 20:43:50 -0000 --0__=0ABBF285DFF612CB8f9e8a93df938690918c0ABBF285DFF612CB Content-type: multipart/alternative; Boundary="1__=0ABBF285DFF612CB8f9e8a93df938690918c0ABBF285DFF612CB" --1__=0ABBF285DFF612CB8f9e8a93df938690918c0ABBF285DFF612CB Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Comments on the draft, mostly editorial in nature: (1) There are still some blockquotes that start with excessive first-li= ne indents, eg., the three quotes on page 5. (2) Page 5, should add comma after "system" in "Reboot, depending on th= e system." (3) Page 5, should pluralize "implementation" in "IKEv2 implementation = can detect." (4) Page 5, should remove "the" in "rules given in the section." (5) Page 6, correct "even has change" to "even has a chance." (6) Page 6, change comma to semicolon in "immediately, in those cases."= (7) Page 6, suggest improving sentence beginning "Note, that" to read "= Note that the IKEv2 specification specifically gives no guidance for the num= ber of retries or the length of timeouts, as these do not affect interoperability." (8) Page 6, suggest changing "messages as hints that will shorten" to r= ead "messages to shorten." (9) Global, need commas after "i.e." (10) Page 6, change "that kind of hints" to either "this kind of hint" = or "these kinds of hints." (11) Page 7, pluralize first word in "Implementation that are not token= takers." (12) Section 4.1, should we specify that the critical bit is set to 0? (13) Page 8, the last line is an orphan. (14) Section 4.2 says the payload "MUST follow . . . and precede . . ."= In general I think the IKEv2 specs have tried to say SHOULD for ordering considerations; should we do so here? (15) Section 4.3 says "SHOULD send a new ticket." I think we mean to s= ay "QCD_TOKEN notification" instead of "ticket." (16) Section 4.5, is it correct to denote the unprotected message as a "request" in the flow diagrams? I think we were careful in RFC 5996 to= denote standalone messages as informational messages rather than informational requests. (17) Section 7, change "new IKE SA consume" to "new IKE SA to consume."= (18) Section 7, suggest changing "re-establishment should occur" to eit= her "would occur" or "will occur." (19) Section 8.1, suggest changing "inter-domain VPN gateway" to either= add "an" before it or pluralize "gateway." Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ipsec@ietf.org Date: 01/10/2011 02:48 AM Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt= Sent by: ipsec-bounces@ietf.org 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 : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-03.txt Pages : 23 Date : 2011-01-09 This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detectio= n-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ipsecme-failure= -detection-03.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBF285DFF612CB8f9e8a93df938690918c0ABBF285DFF612CB Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Comments on the draft, mostly editorial in nature:

(1) There are still some blockquotes that start with excessive first-li= ne indents, eg., the three quotes on page 5.
(2) Page 5, should add comma after "system" in "Reboot, = depending on the system."
(3) Page 5, should pluralize "implementation" in "IKEv2 = implementation can detect."
(4) Page 5, should remove "the" in "rules given in the s= ection."
(5) Page 6, correct "even has change" to "even has a<= /b> chance."
(6) Page 6, change comma to semicolon in "immediately, in those ca= ses."
(7) Page 6, suggest improving sentence beginning "Note, that"= to read "Note that the IKEv2 specification specifically gives no = guidance for the number of retries or the length of timeouts, as these = do not affect interoperability."
(8) Page 6, suggest changing "messages as hints that will shorten&= quot; to read "messages to shorten."
(9) Global, need commas after "i.e."
(10) Page 6, change "that kind of hints" to either "this= kind of hint" or "these kinds of hints."
(11) Page 7, pluralize first word in "Implementation that are not = token takers."
(12) Section 4.1, should we specify that the critical bit is set to 0?<= br> (13) Page 8, the last line is an orphan.
(14) Section 4.2 says the payload "MUST follow . . . and precede .= . ." In general I think the IKEv2 specs have tried to say SHOULD= for ordering considerations; should we do so here?
(15) Section 4.3 says "SHOULD send a new ticket." I think we= mean to say "QCD_TOKEN notification" instead of "ticket= ."
(16) Section 4.5, is it correct to denote the unprotected message as a = "request" in the flow diagrams? I think we were careful in R= FC 5996 to denote standalone messages as informational messages rather = than informational requests.
(17) Section 7, change "new IKE SA consume" to "new IKE = SA to consume."
(18) Section 7, suggest changing "re-establishment should occur&qu= ot; to either "would occur" or "will occur."
(19) Section 8.1, suggest changing "inter-domain VPN gateway"= to either add "an" before it or pluralize "gateway.&quo= t;


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveInternet-Drafts---01= /10/2011 02:48:33 AM---A New Internet-Draft is available from the on-li= ne Internet-Drafts directories. This draft is a work

From: Intern= et-Drafts@ietf.org
To: i-d-anno= unce@ietf.org
Cc: ipsec@ie= tf.org
Date: 01/10/= 2011 02:48 AM
Subject: [IP= sec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt
Sent by: ips= ec-bounces@ietf.org




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           : A Quick Crash Detection M= ethod for IKE
Author(s)       : Y. Nir, et al.
Filename        : draft-ietf-ipsecme-failure-det= ection-03.txt
Pages           : 23
Date            : 2011-01-09

This document describes an extension to the IKEv2 protocol that
allows for faster detection of SA desynchronization using a saved
token.

When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the
= other peer to discover that the reboot has occurred, thus delaying
recovery.  In this text we propose an extension to the protocol, t= hat
allows for recovery immediately following the restart.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft= -ietf-ipsecme-failure-detection-03.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/interne= t-drafts/draft-ietf-ipsecme-failure-detection-03.txt___________= ____________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBF285DFF612CB8f9e8a93df938690918c0ABBF285DFF612CB-- --0__=0ABBF285DFF612CB8f9e8a93df938690918c0ABBF285DFF612CB Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF285DFF612CB8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF285DFF612CB8f9e8a93df938690918c0ABBF285DFF612CB-- From smoonen@us.ibm.com Wed Jan 12 12:51:55 2011 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 E458B28C103; Wed, 12 Jan 2011 12:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=-1.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 QEdaJjOTg1TY; Wed, 12 Jan 2011 12:51:54 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id 3F55D3A6A9C; Wed, 12 Jan 2011 12:51:54 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0CKgAk7012510; Wed, 12 Jan 2011 13:42:10 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0CKsD1F136588; Wed, 12 Jan 2011 13:54:13 -0700 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 p0CKsDUe005296; Wed, 12 Jan 2011 13:54:13 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0CKsDwr005284; Wed, 12 Jan 2011 13:54:13 -0700 In-Reply-To: References: <20110110074502.22466.22300.idtracker@localhost> X-KeepSent: 77545877:B42E95F3-85257816:00726F1F; type=4; name=$KeepSent To: David Wierbowski X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Wed, 12 Jan 2011 15:54:03 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/12/2011 13:54:12 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF285DFE1E98F8f9e8a93df938690918c0ABBF285DFE1E98F" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB 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, 12 Jan 2011 20:51:56 -0000 --0__=0ABBF285DFE1E98F8f9e8a93df938690918c0ABBF285DFE1E98F Content-type: multipart/alternative; Boundary="1__=0ABBF285DFE1E98F8f9e8a93df938690918c0ABBF285DFE1E98F" --1__=0ABBF285DFE1E98F8f9e8a93df938690918c0ABBF285DFE1E98F Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I wonder if there's a way to merge sections 9.2 and 9.4. I think that using the algorithm in 5.2 as specified in 9.4 is really just an extens= ion of this requirement from section 9.2: "A token maker MUST NOT send a QC= D token in an unprotected message for an existing IKE SA." It might be possible to remove a lot of the detail in 9.4 and generaliz= e 9.2 to hint at there being several ways of solving this problem -- 9.2'= s state synchronization and 5.2/9.4's including the remote IP address. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: David Wierbowski/Endicott/IBM@IBMUS To: "ipsec@ietf.org" , ipsec-bounces@ietf.org Cc: Yoav Nir Date: 01/11/2011 12:39 PM Subject: Re: [IPsec] Issue #202: Token makers generating the same token= s without synchronized DB Sent by: ipsec-bounces@ietf.org I agree with Tero that it is unsafe to assume how a load balancer decid= es to distribute traffic. Since section 9.4 (previously 10.4) is in the Security Considerations section it seems reasonable to me that we'd war= n that the algorithms in 5.1 and 5.2 should not be used in cases where lo= ad balancing cluster members share the same QCD token and do not share IKE= SA state. I don't think this restriction precludes the use of QCD in the hot-stan= dby cluster scenario that Yoav mentioned in his previous append. By defini= tion in a hot-standby cluster only one of the cluster members is active at a= ny one time and it is not doing load balancing with its standby members. In the same append Yoav stated that to achieve scalability with your ho= t standby-cluster, you implement load sharing. If you add load balancing= to your hot standby-cluster then the warning in the previous paragraph applies. In otherwords if you want one of your standby members to be a= load balancing target for the active member in the cluster then you nee= d to share the IKE SA state between the active member and the standby member= . I'd recommend that the following text from 9.4 be changed: To thwart this possible attack, such configurations should use a method that considers the taker's IP address, such as the method described in Section 5.2. Dave Wierbowski From: Yoav Nir To: "ipsec@ietf.org" Date: 01/10/2011 03:04 AM Subject: [IPsec] Issue #202: Token makers generating the same tokens= without synchronized DB Sent by: ipsec-bounces@ietf.org Greetings. We have just submitted version -03 of the draft. This closes issues, #= 198, #199, #200, and #201. Which leaves us with just one issue: #202 =3D=3D=3D=3D=3D=3D=3D=3D=3D Issue #202: Token makers generating the sam= e tokens without synchronized DB Section 10.4 of the draft has a use-case where a cluster of gateways sh= are the same QCD token secret, because they back each other up. The twist in this case, is that they don't have synchronized databases,= so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is= effective in getting the other side to restart IKE quickly. The problem is, that without a failover, it may be possible to get a me= mber that does not own the IKE SA to send the QCD token to an attacker. The attacker can then use this QCD token to tear down the IKE SA. The method in section 5.2 tries to address this, by considering the IP address of the token taker in the calculation. Tero claims that this is a scenario that we should not address, and tha= t predicting or prescribing load balancer behavior in inherently dangerou= s. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please send your opinions to the list. This one actually addresses the scope of the document, so it's strange that this comes up as the last issue, but we still have to decide on this. Yoav _______________________________________________ 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 = --1__=0ABBF285DFE1E98F8f9e8a93df938690918c0ABBF285DFE1E98F Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I wonder if there's a way to merge sections 9.2 and 9.4. I think th= at using the algorithm in 5.2 as specified in 9.4 is really just an ext= ension of this requirement from section 9.2: "A token maker MUST N= OT send a QCD token in an unprotected message for an existing IKE SA.&q= uot;

It might be possible to remove a lot of the detail in 9.4 and generaliz= e 9.2 to hint at there being several ways of solving this problem -- 9.= 2's state synchronization and 5.2/9.4's including the remote IP address= .


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveDavid Wierbowski---0= 1/11/2011 12:39:21 PM---I agree with Tero that it is unsafe to assume h= ow a load balancer decides to distribute traffic. Si

From: David = Wierbowski/Endicott/IBM@IBMUS
To: "ip= sec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org
Cc: Yoav Nir= <ynir@checkpoint.com>
Date: 01/11/= 2011 12:39 PM
Subject: Re:= [IPsec] Issue #202: Token makers generating the same tokens without sy= nchronized DB
Sent by: ips= ec-bounces@ietf.org




I agree with Tero that it is unsafe to assume how a load balancer d= ecides
to distribute traffic.  Since section 9.4 (previously 10.4) is in = the
Security Considerations section it seems reasonable to me that we'd war= n
that the algorithms in 5.1 and 5.2 should not be used in cases where lo= ad
balancing cluster members share the same QCD token and do not share IKE= SA
state.

I don't think this restriction precludes the use of QCD in the hot-stan= dby
cluster scenario that Yoav mentioned in his previous append.  By d= efinition
in a hot-standby cluster only one of the cluster members is active at a= ny
one time and it is not doing load balancing with its standby members.
In the same append Yoav stated that to achieve scalability with your ho= t
standby-cluster, you implement load sharing.  If you add load bala= ncing to
your hot standby-cluster then the warning in the previous paragraph
= applies.  In otherwords if you want one of your standby members to= be a
load balancing target for the active member in the cluster then you nee= d to
share the IKE SA state between the active member and the standby member= .

I'd recommend that the following text from 9.4 be changed:

  To thwart this possible attack, such configurations should use = a
  method that considers the taker's IP address, such as the metho= d
  described in Section 5.2.



Dave Wierbowski




From:       Yoav Nir <ynir@checkpoint.com>
To:         "ipsec@ietf.org" <ipsec@ie= tf.org>
Date:       01/10/2011 03:04 AM
Subject:    [IPsec] Issue #202: Token makers generating the s= ame tokens
           without synchronized DB
Sent by:    ipsec-bounces@ietf.org



Greetings.

We have just submitted version -03 of the draft.  This closes issu= es, #198,
#199, #200, and #201.

Which leaves us with just one issue: #202


=3D=3D=3D=3D=3D=3D=3D=3D=3D Issue #202: Token makers generating the sam= e tokens without
synchronized DB
Section 10.4 of the draft has a use-case where a cluster of gateways sh= are
the same QCD token secret, because they back each other up.

The twist in this case, is that they don't have synchronized databases,= so
a fail-over is very much like a reboot - the IKE SA is gone, and QCD is=
effective in getting the other side to restart IKE quickly.

The problem is, that without a failover, it may be possible to get a me= mber
that does not own the IKE SA to send the QCD token to an attacker. The<= br> attacker can then use this QCD token to tear down the IKE SA.

The method in section 5.2 tries to address this, by considering the IP<= br> address of the token taker in the calculation.

Tero claims that this is a scenario that we should not address, and tha= t
predicting or prescribing load balancer behavior in inherently dangerou= s.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Please send your opinions to the list. This one actually addresses the<= br> scope of the document, so it's strange that this comes up as the last issue, but we still have to decide on this.

Yoav


_______________________________________________
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

= --1__=0ABBF285DFE1E98F8f9e8a93df938690918c0ABBF285DFE1E98F-- --0__=0ABBF285DFE1E98F8f9e8a93df938690918c0ABBF285DFE1E98F Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF285DFE1E98F8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF285DFE1E98F8f9e8a93df938690918c0ABBF285DFE1E98F-- From welterk@us.ibm.com Wed Jan 12 13:18:24 2011 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 BE9323A6A91 for ; Wed, 12 Jan 2011 13:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 IRxYiaXsx30Q for ; Wed, 12 Jan 2011 13:18:23 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 740E43A69C5 for ; Wed, 12 Jan 2011 13:18:23 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0CKuQ1p014879 for ; Wed, 12 Jan 2011 15:56:40 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 98D044DE8053 for ; Wed, 12 Jan 2011 16:17:39 -0500 (EST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0CLKgEb477880 for ; Wed, 12 Jan 2011 16:20:43 -0500 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 p0CLKgc8027886 for ; Wed, 12 Jan 2011 14:20:42 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0CLKgYI027880 for ; Wed, 12 Jan 2011 14:20:42 -0700 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 042D8DC8:64349015-88257816:0073DD1F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Wed, 12 Jan 2011 13:20:41 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/12/2011 14:20:42, Serialize complete at 01/12/2011 14:20:42 Content-Type: multipart/alternative; boundary="=_alternative 0075412E88257816_=" X-Content-Scanned: Fidelis XPS MAILER Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-01 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, 12 Jan 2011 21:18:24 -0000 This is a multipart message in MIME format. --=_alternative 0075412E88257816_= Content-Type: text/plain; charset="US-ASCII" In the thread "Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00", Yoav proposed: "having an IKE_AUTH exchange in the middle of the IKE SA lifetime. Suppose the IKE SA has been around for a couple of hours, and has been used for creating some child SAs, why not keep it and just pass one or more IKE_AUTH exchanges?" draft-welter-ipsecme-ikev2-reauth-01 specifies this alternative design. To refresh everyone's memory on the problems that the draft aims to solve, I'll include the introductory text from the new version of the draft here: "IKE SA reauthentication as defined in [IKEv2] is accomplished by creating a new IKE SA, creating new Child SAs, and deleting the old IKE SA. Assuming that the old IKE SA has n Child SAs, reauthentication as defined in [IKEv2] requires at least n+1 message exchanges. This style of reauthentication does not scale well when n is large. The extension described in this document allows reauthentication of an IKE SA using a single IKE_AUTH exchange on the IKE SA to be reauthenticated without creating a new IKE SA or new Child SAs. The terms IKEv2, IKEv2 SA, and Child SA and the various IKEv2 exchanges are defined in [IKEv2] Other problems with IKE SA reauthentication as defined in [IKEv2] include: o Simultaneous IKE SA reauthentication may result in redundant SAs. o Child SAs for which an internal address was assigned using the Configuration Payload may experience a connection disruption for reassignment of an internal address. o While [IKEv2] describes how to handle exchange collisions that may occur during IKE SA rekeying, it does not do so for exchange collisions that may occur during reauthentication which could inhibit interoperability in such cases." Please share your comments on draft-welter-ipsecme-ikev2-reauth-01. Thanks, Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) ipsec-bounces@ietf.org wrote on 01/12/2011 12:32:07 PM: > [image removed] > > [IPsec] draft-welter-ipsecme-ikev2-reauth-01 > > Keith Welter > > to: > > ipsec > > 01/12/2011 12:36 PM > > Sent by: > > ipsec-bounces@ietf.org > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has > been successfully submitted by Keith Welter and posted to the IETF repository. > > Filename: draft-welter-ipsecme-ikev2-reauth > Revision: 01 > Title: Reauthentication Extension for IKEv2 > Creation_date: 2011-01-12 > WG ID: Independent Submission > Number_of_pages: 6 > > Abstract: > This document describes an extension to the Internet Key Exchange > version 2 (IKEv2) protocol that allows an IKEv2 Security Association > (SA) to be reauthenticated without creating a new IKE SA or new Child > SAs. > > > > The IETF Secretariat. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0075412E88257816_= Content-Type: text/html; charset="US-ASCII"
In the thread "Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00", Yoav proposed:
"having an IKE_AUTH exchange in the middle of the IKE SA lifetime. Suppose the IKE SA has been around for a couple of hours, and has been used for creating some child SAs, why not keep it and just pass one or more IKE_AUTH exchanges?"

draft-welter-ipsecme-ikev2-reauth-01 specifies this alternative design.

To refresh everyone's memory on the problems that the draft aims to solve, I'll include the introductory text from the new version of the draft here:

"IKE SA reauthentication as defined in [IKEv2] is accomplished by creating a new IKE SA, creating new Child SAs, and deleting the old IKE SA.  Assuming that the old IKE SA has n Child SAs, reauthentication as defined in [IKEv2] requires at least n+1 message exchanges.  This style of reauthentication does not scale well when n is large.  The extension described in this document allows reauthentication of an IKE SA using a single IKE_AUTH exchange on the IKE SA to be reauthenticated without creating a new IKE SA or new Child SAs.  The terms IKEv2, IKEv2 SA, and Child SA and the various IKEv2 exchanges are defined in [IKEv2]

Other problems with IKE SA reauthentication as defined in [IKEv2] include:

   o  Simultaneous IKE SA reauthentication may result in redundant SAs.

   o  Child SAs for which an internal address was assigned using the Configuration Payload may experience a connection disruption for reassignment of an internal address.

   o  While [IKEv2] describes how to handle exchange collisions that may occur during IKE SA rekeying, it does not do so for exchange collisions that may occur during reauthentication which could inhibit interoperability in such cases."

Please share your comments on draft-welter-ipsecme-ikev2-reauth-01.

Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

ipsec-bounces@ietf.org wrote on 01/12/2011 12:32:07 PM:

> [image removed]
>
> [IPsec] draft-welter-ipsecme-ikev2-reauth-01
>
> Keith Welter
>
> to:
>
> ipsec
>
> 01/12/2011 12:36 PM
>
> Sent by:
>
> ipsec-bounces@ietf.org
>
>
> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has
> been successfully submitted by Keith Welter and posted to the IETF repository.
>
> Filename:                  draft-welter-ipsecme-ikev2-reauth
> Revision:                  01
> Title:                                   Reauthentication Extension for IKEv2
> Creation_date:                  2011-01-12
> WG ID:                                   Independent Submission
> Number_of_pages: 6
>
> Abstract:
> This document describes an extension to the Internet Key Exchange
> version 2 (IKEv2) protocol that allows an IKEv2 Security Association
> (SA) to be reauthenticated without creating a new IKE SA or new Child
> SAs.
>                                                                              
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
 --=_alternative 0075412E88257816_=-- From smoonen@us.ibm.com Thu Jan 13 06:46:36 2011 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 6B19628B23E; Thu, 13 Jan 2011 06:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 WC8Kpxy5LRIZ; Thu, 13 Jan 2011 06:46:34 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id A3B4A3A6B32; Thu, 13 Jan 2011 06:46:34 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0DEah7Y002942; Thu, 13 Jan 2011 07:36:43 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0DEmlhc141794; Thu, 13 Jan 2011 07:48:47 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0DEmk2I001308; Thu, 13 Jan 2011 07:48:46 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0DEmktx001278; Thu, 13 Jan 2011 07:48:46 -0700 In-Reply-To: References: <20110110074502.22466.22300.idtracker@localhost> X-KeepSent: 1218E7F2:9CDE3B0B-85257817:0050A9F7; type=4; name=$KeepSent To: David Wierbowski X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Thu, 13 Jan 2011 09:47:59 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/13/2011 07:48:45 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF284DFC32F678f9e8a93df938690918c0ABBF284DFC32F67" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB 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, 13 Jan 2011 14:46:36 -0000 --0__=0ABBF284DFC32F678f9e8a93df938690918c0ABBF284DFC32F67 Content-type: multipart/alternative; Boundary="1__=0ABBF284DFC32F678f9e8a93df938690918c0ABBF284DFC32F67" --1__=0ABBF284DFC32F678f9e8a93df938690918c0ABBF284DFC32F67 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Combining the two sections could also make it clearer that 5.2/9.4 may = not be a "complete" solution for any given environment. The approach of 5.2/9.4 solves the problem of an independent attacker using a different= source IP address, but not a proximate/MitM attacker as is currently addressed in 9.2. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Scott C Moonen/Raleigh/IBM To: David Wierbowski/Endicott/IBM@IBMUS Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir Date: 01/12/2011 03:54 PM Subject: Re: [IPsec] Issue #202: Token makers generating the same token= s without synchronized DB I wonder if there's a way to merge sections 9.2 and 9.4. I think that using the algorithm in 5.2 as specified in 9.4 is really just an extens= ion of this requirement from section 9.2: "A token maker MUST NOT send a QC= D token in an unprotected message for an existing IKE SA." It might be possible to remove a lot of the detail in 9.4 and generaliz= e 9.2 to hint at there being several ways of solving this problem -- 9.2'= s state synchronization and 5.2/9.4's including the remote IP address. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: David Wierbowski/Endicott/IBM@IBMUS To: "ipsec@ietf.org" , ipsec-bounces@ietf.org Cc: Yoav Nir Date: 01/11/2011 12:39 PM Subject: Re: [IPsec] Issue #202: Token makers generating the same token= s without synchronized DB Sent by: ipsec-bounces@ietf.org I agree with Tero that it is unsafe to assume how a load balancer decid= es to distribute traffic. Since section 9.4 (previously 10.4) is in the Security Considerations section it seems reasonable to me that we'd war= n that the algorithms in 5.1 and 5.2 should not be used in cases where lo= ad balancing cluster members share the same QCD token and do not share IKE= SA state. I don't think this restriction precludes the use of QCD in the hot-stan= dby cluster scenario that Yoav mentioned in his previous append. By defini= tion in a hot-standby cluster only one of the cluster members is active at a= ny one time and it is not doing load balancing with its standby members. In the same append Yoav stated that to achieve scalability with your ho= t standby-cluster, you implement load sharing. If you add load balancing= to your hot standby-cluster then the warning in the previous paragraph applies. In otherwords if you want one of your standby members to be a= load balancing target for the active member in the cluster then you nee= d to share the IKE SA state between the active member and the standby member= . I'd recommend that the following text from 9.4 be changed: To thwart this possible attack, such configurations should use a method that considers the taker's IP address, such as the method described in Section 5.2. Dave Wierbowski From: Yoav Nir To: "ipsec@ietf.org" Date: 01/10/2011 03:04 AM Subject: [IPsec] Issue #202: Token makers generating the same tokens= without synchronized DB Sent by: ipsec-bounces@ietf.org Greetings. We have just submitted version -03 of the draft. This closes issues, #= 198, #199, #200, and #201. Which leaves us with just one issue: #202 =3D=3D=3D=3D=3D=3D=3D=3D=3D Issue #202: Token makers generating the sam= e tokens without synchronized DB Section 10.4 of the draft has a use-case where a cluster of gateways sh= are the same QCD token secret, because they back each other up. The twist in this case, is that they don't have synchronized databases,= so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is= effective in getting the other side to restart IKE quickly. The problem is, that without a failover, it may be possible to get a me= mber that does not own the IKE SA to send the QCD token to an attacker. The attacker can then use this QCD token to tear down the IKE SA. The method in section 5.2 tries to address this, by considering the IP address of the token taker in the calculation. Tero claims that this is a scenario that we should not address, and tha= t predicting or prescribing load balancer behavior in inherently dangerou= s. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please send your opinions to the list. This one actually addresses the scope of the document, so it's strange that this comes up as the last issue, but we still have to decide on this. Yoav _______________________________________________ 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 = --1__=0ABBF284DFC32F678f9e8a93df938690918c0ABBF284DFC32F67 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Combining the two sections could also make it clearer that 5.2/9.4 m= ay not be a "complete" solution for any given environment. T= he approach of 5.2/9.4 solves the problem of an independent attacker us= ing a different source IP address, but not a proximate/MitM attacker as= is currently addressed in 9.2.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveScott C Moonen---01/= 12/2011 03:54:03 PM---I wonder if there's a way to merge sections 9.2 a= nd 9.4. I think that using the algorithm in 5.2 as

From: Scott = C Moonen/Raleigh/IBM
To: David Wi= erbowski/Endicott/IBM@IBMUS
Cc: "ip= sec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org, Yoav= Nir <ynir@checkpoint.com>
Date: 01/12/= 2011 03:54 PM
Subject: Re:= [IPsec] Issue #202: Token makers generating the same tokens without sy= nchronized DB



I wonder if there's a way to merge sections 9.2 and 9.4. I think that = using the algorithm in 5.2 as specified in 9.4 is really just an extens= ion of this requirement from section 9.2: "A token maker MUST NOT = send a QCD token in an unprotected message for an existing IKE SA."= ;

It might be possible to remove a lot of the detail in 9.4 and generaliz= e 9.2 to hint at there being several ways of solving this problem -- 9.= 2's state synchronization and 5.2/9.4's including the remote IP address= .


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen


3D"InactiveDavid Wierbowski---0= 1/11/2011 12:39:21 PM---I agree with Tero that it is unsafe to assume h= ow a load balancer decides to distribute traffic. Si

From: David = Wierbowski/Endicott/IBM@IBMUS
To: "ip= sec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org
Cc: Yoav Nir= <ynir@checkpoint.com>
Date: 01/11/= 2011 12:39 PM
Subject: Re:= [IPsec] Issue #202: Token makers generating the same tokens without sy= nchronized DB
Sent by: ips= ec-bounces@ietf.org



I agree with Tero that it is unsafe to assume how a load balancer d= ecides
to distribute traffic.  Since section 9.4 (previously 10.4) is in = the
Security Considerations section it seems reasonable to me that we'd war= n
that the algorithms in 5.1 and 5.2 should not be used in cases where lo= ad
balancing cluster members share the same QCD token and do not share IKE= SA
state.

I don't think this restriction precludes the use of QCD in the hot-stan= dby
cluster scenario that Yoav mentioned in his previous append.  By d= efinition
in a hot-standby cluster only one of the cluster members is active at a= ny
one time and it is not doing load balancing with its standby members.
In the same append Yoav stated that to achieve scalability with your ho= t
standby-cluster, you implement load sharing.  If you add load bala= ncing to
your hot standby-cluster then the warning in the previous paragraph
= applies.  In otherwords if you want one of your standby members to= be a
load balancing target for the active member in the cluster then you nee= d to
share the IKE SA state between the active member and the standby member= .

I'd recommend that the following text from 9.4 be changed:

  To thwart this possible attack, such configurations should use = a
  method that considers the taker's IP address, such as the metho= d
  described in Section 5.2.



Dave Wierbowski




From:       Yoav Nir <ynir@checkpoint.com>
To:         "ipsec@ietf.org" <ipsec@ie= tf.org>
Date:       01/10/2011 03:04 AM
Subject:    [IPsec] Issue #202: Token makers generating the s= ame tokens
           without synchronized DB
Sent by:    ipsec-bounces@ietf.org



Greetings.

We have just submitted version -03 of the draft.  This closes issu= es, #198,
#199, #200, and #201.

Which leaves us with just one issue: #202


=3D=3D=3D=3D=3D=3D=3D=3D=3D Issue #202: Token makers generating the sam= e tokens without
synchronized DB
Section 10.4 of the draft has a use-case where a cluster of gateways sh= are
the same QCD token secret, because they back each other up.

The twist in this case, is that they don't have synchronized databases,= so
a fail-over is very much like a reboot - the IKE SA is gone, and QCD is=
effective in getting the other side to restart IKE quickly.

The problem is, that without a failover, it may be possible to get a me= mber
that does not own the IKE SA to send the QCD token to an attacker. The<= br> attacker can then use this QCD token to tear down the IKE SA.

The method in section 5.2 tries to address this, by considering the IP<= br> address of the token taker in the calculation.

Tero claims that this is a scenario that we should not address, and tha= t
predicting or prescribing load balancer behavior in inherently dangerou= s.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Please send your opinions to the list. This one actually addresses the<= br> scope of the document, so it's strange that this comes up as the last issue, but we still have to decide on this.

Yoav


_______________________________________________
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

= --1__=0ABBF284DFC32F678f9e8a93df938690918c0ABBF284DFC32F67-- --0__=0ABBF284DFC32F678f9e8a93df938690918c0ABBF284DFC32F67 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF284DFC32F678f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF284DFC32F678f9e8a93df938690918c0ABBF284DFC32F67-- From wierbows@us.ibm.com Thu Jan 13 08:13:46 2011 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 B6F533A6A11; Thu, 13 Jan 2011 08:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.889 X-Spam-Level: X-Spam-Status: No, score=-4.889 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 Dz2dN86GSfkH; Thu, 13 Jan 2011 08:13:45 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 27F893A6BBB; Thu, 13 Jan 2011 08:13:39 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0DG1NIL001152; Thu, 13 Jan 2011 11:01:23 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 92502728378; Thu, 13 Jan 2011 11:11:06 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0DGB6uM358096; Thu, 13 Jan 2011 11:11:06 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0DGB5DF016050; Thu, 13 Jan 2011 14:11:06 -0200 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0DGB420015962; Thu, 13 Jan 2011 14:11:04 -0200 In-Reply-To: References: <20110110074502.22466.22300.idtracker@localhost> X-KeepSent: 62A79669:37415B1B-85257817:0051C8C4; type=4; name=$KeepSent To: Scott C Moonen X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: David Wierbowski Date: Thu, 13 Jan 2011 11:11:03 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 01/13/2011 11:11:03 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBF284DFC24E548f9e8a93df938690918c0ABBF284DFC24E54" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB 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, 13 Jan 2011 16:13:46 -0000 --0__=0ABBF284DFC24E548f9e8a93df938690918c0ABBF284DFC24E54 Content-type: text/plain; charset=US-ASCII Scott, I agree that there is relationship between sections 9.2 and 9.4. The statement that "all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster" which is found in 9.2 is consistent with my comment that " the algorithms in 5.1 and 5.2 should not be used in cases where load balancing cluster members share the same QCD token and do not share IKE SA state." Although I suppose I should have said same QCD_SECRET instead of QCD token to be more accurate. I could see why you would say that the algorithm in 5.2 as justified in section 9.4 is being used to meet the requirement that "A token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA." Certainly if we do not include IP address it is possible that a cluster member could send the QCD token of an existing IKE SA to an attacker using a different source IP address. In that case we'd be unknowingly violating the rule. By adding the ip address of the taker we prevent this. I think you are correct that the two sections could be combined, but I'll defer to Yoav on that. As an aside I see that I cut and paste the wrong paragraph in my append. I had actually intended to cut and paste the last paragraph of 9.4 and I now see that I cut and paste the next to last paragraph in section 9.4 :>). Dave Wierbowski From: Scott C Moonen/Raleigh/IBM@IBMUS To: David Wierbowski/Endicott/IBM@IBMUS Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir Date: 01/13/2011 09:50 AM Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB Sent by: ipsec-bounces@ietf.org Combining the two sections could also make it clearer that 5.2/9.4 may not be a "complete" solution for any given environment. The approach of 5.2/9.4 solves the problem of an independent attacker using a different source IP address, but not a proximate/MitM attacker as is currently addressed in 9.2. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen (Embedded image moved to file: pic34804.gif)Inactive hide details for Scott C Moonen---01/12/2011 03:54:03 PM---I wonder if there's a way to merge sections 9.2 and 9.4. IScott C Moonen---01/12/2011 03:54:03 PM---I wonder if there's a way to merge sections 9.2 and 9.4. I think that using the algorithm in 5.2 as From: Scott C Moonen/Raleigh/IBM To: David Wierbowski/Endicott/IBM@IBMUS Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir Date: 01/12/2011 03:54 PM Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB I wonder if there's a way to merge sections 9.2 and 9.4. I think that using the algorithm in 5.2 as specified in 9.4 is really just an extension of this requirement from section 9.2: "A token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA." It might be possible to remove a lot of the detail in 9.4 and generalize 9.2 to hint at there being several ways of solving this problem -- 9.2's state synchronization and 5.2/9.4's including the remote IP address. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen (Embedded image moved to file: pic11871.gif)Inactive hide details for David Wierbowski---01/11/2011 12:39:21 PM---I agree with Tero that it is unsafe to assume how a load David Wierbowski---01/11/2011 12:39:21 PM---I agree with Tero that it is unsafe to assume how a load balancer decides to distribute traffic. Si From: David Wierbowski/Endicott/IBM@IBMUS To: "ipsec@ietf.org" , ipsec-bounces@ietf.org Cc: Yoav Nir Date: 01/11/2011 12:39 PM Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB Sent by: ipsec-bounces@ietf.org I agree with Tero that it is unsafe to assume how a load balancer decides to distribute traffic. Since section 9.4 (previously 10.4) is in the Security Considerations section it seems reasonable to me that we'd warn that the algorithms in 5.1 and 5.2 should not be used in cases where load balancing cluster members share the same QCD token and do not share IKE SA state. I don't think this restriction precludes the use of QCD in the hot-standby cluster scenario that Yoav mentioned in his previous append. By definition in a hot-standby cluster only one of the cluster members is active at any one time and it is not doing load balancing with its standby members. In the same append Yoav stated that to achieve scalability with your hot standby-cluster, you implement load sharing. If you add load balancing to your hot standby-cluster then the warning in the previous paragraph applies. In otherwords if you want one of your standby members to be a load balancing target for the active member in the cluster then you need to share the IKE SA state between the active member and the standby member. I'd recommend that the following text from 9.4 be changed: To thwart this possible attack, such configurations should use a method that considers the taker's IP address, such as the method described in Section 5.2. Dave Wierbowski From: Yoav Nir To: "ipsec@ietf.org" Date: 01/10/2011 03:04 AM Subject: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB Sent by: ipsec-bounces@ietf.org Greetings. We have just submitted version -03 of the draft. This closes issues, #198, #199, #200, and #201. Which leaves us with just one issue: #202 ========= Issue #202: Token makers generating the same tokens without synchronized DB Section 10.4 of the draft has a use-case where a cluster of gateways share the same QCD token secret, because they back each other up. The twist in this case, is that they don't have synchronized databases, so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is effective in getting the other side to restart IKE quickly. The problem is, that without a failover, it may be possible to get a member that does not own the IKE SA to send the QCD token to an attacker. The attacker can then use this QCD token to tear down the IKE SA. The method in section 5.2 tries to address this, by considering the IP address of the token taker in the calculation. Tero claims that this is a scenario that we should not address, and that predicting or prescribing load balancer behavior in inherently dangerous. ======================= Please send your opinions to the list. This one actually addresses the scope of the document, so it's strange that this comes up as the last issue, but we still have to decide on this. Yoav _______________________________________________ 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --0__=0ABBF284DFC24E548f9e8a93df938690918c0ABBF284DFC24E54 Content-type: image/gif; name="pic34804.gif" Content-Disposition: attachment; filename="pic34804.gif" Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF284DFC24E548f9e8a93df938690918c0ABBF284DFC24E54 Content-type: image/gif; name="pic11871.gif" Content-Disposition: attachment; filename="pic11871.gif" Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF284DFC24E548f9e8a93df938690918c0ABBF284DFC24E54-- From yaronf.ietf@gmail.com Fri Jan 14 00:45:28 2011 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 AFF433A6C5B for ; Fri, 14 Jan 2011 00:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10kePJpvQywE for ; Fri, 14 Jan 2011 00:45:27 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 00F6D3A6C5A for ; Fri, 14 Jan 2011 00:45:26 -0800 (PST) Received: by wyf23 with SMTP id 23so2699475wyf.31 for ; Fri, 14 Jan 2011 00:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=X77dv1FjxVZRPQ18qEXy3muxH2Fh8cfjUbiqB2/G8Rs=; b=xgqOuzuyBIhliNw42CYgiAF8/1LTniKn6Ln9aKdWTl1LDaz6wIVwguIzwe9WsAGPoy 4Vik+5Accmxo4j5ZtM2YC66EdXO2td2NbxGLEvTFWMrz55jDais9Fe8O0aUPkcJI2Vcx mEvHxeMjyvCVFVTCpUevdrLEzXuQk7CqO434s= 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; b=s259Y4VuMdt2hW1NHUZvIC5s23w6CjVpEiP5uXnfgxiN84BdN9UpvMwYz8GUvj6Zbz 3HYFvr0EWuKd0QzDGWKjJ8nAEIwak/1GUYU7TOZ23HFJxTrWWZ0OUtrOZqAYrizg9o4U F25cQQRotHWsbHTZEljK+panxsF+tMFY9Q2EU= Received: by 10.227.144.7 with SMTP id x7mr428340wbu.115.1294994870054; Fri, 14 Jan 2011 00:47:50 -0800 (PST) Received: from [10.0.0.4] ([109.67.17.212]) by mx.google.com with ESMTPS id 11sm725910wbj.1.2011.01.14.00.47.47 (version=SSLv3 cipher=RC4-MD5); Fri, 14 Jan 2011 00:47:49 -0800 (PST) Message-ID: <4D300DA7.2010003@gmail.com> Date: Fri, 14 Jan 2011 10:47:35 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Keith Welter References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080800070707010300080102" Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-01 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, 14 Jan 2011 08:45:28 -0000 This is a multi-part message in MIME format. --------------080800070707010300080102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Keith, I think this version makes a lot of sense. A few comments: * I don't like the asymmetrical nature of the notification, which implies that only the original initiator can initiate the second IKE_AUTH. There may be cases when the responder would like to reauthenticate (e.g. mutual EAP with passwords). So I suggest to have both peers send the notification if they support this extension. * Please say explicitly whether/how this extension interacts with RFC 6023: can the reauthenticated IKE SA be childless? * The introduction mentions three problems. Please add text somewhere on how they are solved by this proposal. * Typo in Sec. 4: "MUST be the same as the as the SPIs". Thanks, Yaron On 12/01/2011 23:20, Keith Welter wrote: > > In the thread "Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00", Yoav > proposed: > "having an IKE_AUTH exchange in the middle of the IKE SA lifetime. > Suppose the IKE SA has been around for a couple of hours, and has been > used for creating some child SAs, why not keep it and just pass one or > more IKE_AUTH exchanges?" > > draft-welter-ipsecme-ikev2-reauth-01 specifies this alternative design. > > To refresh everyone's memory on the problems that the draft aims to > solve, I'll include the introductory text from the new version of the > draft here: > > "IKE SA reauthentication as defined in [IKEv2] is accomplished by > creating a new IKE SA, creating new Child SAs, and deleting the old > IKE SA. Assuming that the old IKE SA has n Child SAs, > reauthentication as defined in [IKEv2] requires at least n+1 message > exchanges. This style of reauthentication does not scale well when n > is large. The extension described in this document allows > reauthentication of an IKE SA using a single IKE_AUTH exchange on the > IKE SA to be reauthenticated without creating a new IKE SA or new > Child SAs. The terms IKEv2, IKEv2 SA, and Child SA and the various > IKEv2 exchanges are defined in [IKEv2] > > Other problems with IKE SA reauthentication as defined in [IKEv2] > include: > > o Simultaneous IKE SA reauthentication may result in redundant SAs. > > o Child SAs for which an internal address was assigned using the > Configuration Payload may experience a connection disruption for > reassignment of an internal address. > > o While [IKEv2] describes how to handle exchange collisions that > may occur during IKE SA rekeying, it does not do so for exchange > collisions that may occur during reauthentication which could inhibit > interoperability in such cases." > > Please share your comments on draft-welter-ipsecme-ikev2-reauth-01. > > Thanks, > > Keith Welter > IBM z/OS Communications Server Developer > 1-415-545-2694 (T/L: 473-2694) > > > ipsec-bounces@ietf.org wrote on 01/12/2011 12:32:07 PM: > > > [image removed] > > > > [IPsec] draft-welter-ipsecme-ikev2-reauth-01 > > > > Keith Welter > > > > to: > > > > ipsec > > > > 01/12/2011 12:36 PM > > > > Sent by: > > > > ipsec-bounces@ietf.org > > > > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has > > been successfully submitted by Keith Welter and posted to the IETF > repository. > > > > Filename: draft-welter-ipsecme-ikev2-reauth > > Revision: 01 > > Title: Reauthentication Extension > for IKEv2 > > Creation_date: 2011-01-12 > > WG ID: Independent Submission > > Number_of_pages: 6 > > > > Abstract: > > This document describes an extension to the Internet Key Exchange > > version 2 (IKEv2) protocol that allows an IKEv2 Security Association > > (SA) to be reauthenticated without creating a new IKE SA or new Child > > SAs. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > 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 --------------080800070707010300080102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Keith,

I think this version makes a lot of sense. A few comments:
  • I don't like the asymmetrical nature of the notification, which implies that only the original initiator can initiate the second IKE_AUTH. There may be cases when the responder would like to reauthenticate (e.g. mutual EAP with passwords). So I suggest to have both peers send the notification if they support this extension.
  • Please say explicitly whether/how this extension interacts with RFC 6023: can the reauthenticated IKE SA be childless?
  • The introduction mentions three problems. Please add text somewhere on how they are solved by this proposal.
  • Typo in Sec. 4: "MUST be the same as the as the SPIs".
Thanks,
    Yaron

On 12/01/2011 23:20, Keith Welter wrote:

In the thread "Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00", Yoav proposed:
"having an IKE_AUTH exchange in the middle of the IKE SA lifetime. Suppose the IKE SA has been around for a couple of hours, and has been used for creating some child SAs, why not keep it and just pass one or more IKE_AUTH exchanges?"

draft-welter-ipsecme-ikev2-reauth-01 specifies this alternative design.

To refresh everyone's memory on the problems that the draft aims to solve, I'll include the introductory text from the new version of the draft here:

"IKE SA reauthentication as defined in [IKEv2] is accomplished by creating a new IKE SA, creating new Child SAs, and deleting the old IKE SA.  Assuming that the old IKE SA has n Child SAs, reauthentication as defined in [IKEv2] requires at least n+1 message exchanges.  This style of reauthentication does not scale well when n is large.  The extension described in this document allows reauthentication of an IKE SA using a single IKE_AUTH exchange on the IKE SA to be reauthenticated without creating a new IKE SA or new Child SAs.  The terms IKEv2, IKEv2 SA, and Child SA and the various IKEv2 exchanges are defined in [IKEv2]

Other problems with IKE SA reauthentication as defined in [IKEv2] include:

   o  Simultaneous IKE SA reauthentication may result in redundant SAs.

   o  Child SAs for which an internal address was assigned using the Configuration Payload may experience a connection disruption for reassignment of an internal address.

   o  While [IKEv2] describes how to handle exchange collisions that may occur during IKE SA rekeying, it does not do so for exchange collisions that may occur during reauthentication which could inhibit interoperability in such cases."

Please share your comments on draft-welter-ipsecme-ikev2-reauth-01.

Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

ipsec-bounces@ietf.org wrote on 01/12/2011 12:32:07 PM:

> [image removed]
>
> [IPsec] draft-welter-ipsecme-ikev2-reauth-01
>
> Keith Welter
>
> to:
>
> ipsec
>
> 01/12/2011 12:36 PM
>
> Sent by:
>
> ipsec-bounces@ietf.org
>
>
> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-01.txt has
> been successfully submitted by Keith Welter and posted to the IETF repository.
>
> Filename:                  draft-welter-ipsecme-ikev2-reauth
> Revision:                  01
> Title:                                   Reauthentication Extension for IKEv2
> Creation_date:                  2011-01-12
> WG ID:                                   Independent Submission
> Number_of_pages: 6
>
> Abstract:
> This document describes an extension to the Internet Key Exchange
> version 2 (IKEv2) protocol that allows an IKEv2 Security Association
> (SA) to be reauthenticated without creating a new IKE SA or new Child
> SAs.
>                                                                              
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> 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

--------------080800070707010300080102-- From welterk@us.ibm.com Fri Jan 14 11:48:40 2011 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 2E5D63A6BA7 for ; Fri, 14 Jan 2011 11:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=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 MaM1KYWPaH2l for ; Fri, 14 Jan 2011 11:48:39 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 2849A3A6A58 for ; Fri, 14 Jan 2011 11:48:39 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0EJe16Z032648 for ; Fri, 14 Jan 2011 12:40:01 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0EJowRu180652 for ; Fri, 14 Jan 2011 12:50:58 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0EJtQrf031992 for ; Fri, 14 Jan 2011 12:55:26 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0EJtQvx031985; Fri, 14 Jan 2011 12:55:26 -0700 In-Reply-To: <4D300DA7.2010003@gmail.com> References: <4D300DA7.2010003@gmail.com> To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 5AE96352:AB708A0E-88257818:006C6C27; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Fri, 14 Jan 2011 11:50:57 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/14/2011 12:50:57, Serialize complete at 01/14/2011 12:50:57 Content-Type: multipart/alternative; boundary="=_alternative 006D080C88257818_=" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-01 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, 14 Jan 2011 19:48:40 -0000 This is a multipart message in MIME format. --=_alternative 006D080C88257818_= Content-Type: text/plain; charset="US-ASCII" Version 02 is in the mail. > Hi Keith, > > I think this version makes a lot of sense. Thanks. > A few comments: > I don't like the asymmetrical nature of the notification, which > implies that only the original initiator can initiate the second > IKE_AUTH. There may be cases when the responder would like to > reauthenticate (e.g. mutual EAP with passwords). So I suggest to > have both peers send the notification if they support this extension. Fixed in version 02. > Please say explicitly whether/how this extension interacts with RFC > 6023: can the reauthenticated IKE SA be childless? My intent was to permit reauthentication of a childless SA. That is now explicitly stated in version 02. > The introduction mentions three problems. Please add text somewhere > on how they are solved by this proposal. I beefed-up the introduction to state how these problems are solved in version 02. > Typo in Sec. 4: "MUST be the same as the as the SPIs". Fixed in 02. > Thanks, > Yaron --=_alternative 006D080C88257818_= Content-Type: text/html; charset="US-ASCII"
Version 02 is in the mail.

> Hi Keith,
>
> I think this version makes a lot of sense.
Thanks.

> A few comments:
> I don't like the asymmetrical nature of the notification, which
> implies that only the original initiator can initiate the second
> IKE_AUTH. There may be cases when the responder would like to
> reauthenticate (e.g. mutual EAP with passwords). So I suggest to
> have both peers send the notification if they support this extension.
Fixed in version 02.

> Please say explicitly whether/how this extension interacts with RFC
> 6023: can the reauthenticated IKE SA be childless?
My intent was to permit reauthentication of a childless SA.  That is now explicitly stated in version 02.

> The introduction mentions three problems. Please add text somewhere
> on how they are solved by this proposal.
I beefed-up the introduction to state how these problems are solved in version 02.

> Typo in Sec. 4: "MUST be the same as the as the SPIs".
Fixed in 02.

> Thanks,
>     Yaron
 --=_alternative 006D080C88257818_=-- From welterk@us.ibm.com Fri Jan 14 11:51:51 2011 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 CB3813A6BC6 for ; Fri, 14 Jan 2011 11:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HTML_MESSAGE=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 y+mpG7JUVA9n for ; Fri, 14 Jan 2011 11:51:49 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 766163A6BCC for ; Fri, 14 Jan 2011 11:51:49 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0EJm6pA015834 for ; Fri, 14 Jan 2011 12:48:06 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p0EJs8L3233394 for ; Fri, 14 Jan 2011 12:54:09 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0EJs8AC018449 for ; Fri, 14 Jan 2011 12:54:08 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0EJs8Bl018413 for ; Fri, 14 Jan 2011 12:54:08 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 3BE5DE68:D7665C2D-88257818:006D11C6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Fri, 14 Jan 2011 11:54:07 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/14/2011 12:54:07, Serialize complete at 01/14/2011 12:54:07 Content-Type: multipart/alternative; boundary="=_alternative 006D527188257818_=" Subject: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 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, 14 Jan 2011 19:51:51 -0000 This is a multipart message in MIME format. --=_alternative 006D527188257818_= Content-Type: text/plain; charset="US-ASCII" I submitted draft-welter-ipsecme-ikev2-reauth-02 to address the comments from Yaron. Thanks Yaron! Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-02.txt has > been successfully submitted by Keith Welter and posted to the IETF repository. > > Filename: draft-welter-ipsecme-ikev2-reauth > Revision: 02 > Title: Reauthentication Extension for IKEv2 > Creation_date: 2011-01-14 > WG ID: Independent Submission > Number_of_pages: 6 > > Abstract: > This document describes an extension to the Internet Key Exchange > version 2 (IKEv2) protocol that allows an IKEv2 Security Association > (SA) to be reauthenticated without creating a new IKE SA or new Child > SAs. > > > > The IETF Secretariat. > > --=_alternative 006D527188257818_= Content-Type: text/html; charset="US-ASCII"
I submitted draft-welter-ipsecme-ikev2-reauth-02 to address the comments from Yaron.  Thanks Yaron!

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-02.txt has
> been successfully submitted by Keith Welter and posted to the IETF repository.
>
> Filename:    draft-welter-ipsecme-ikev2-reauth
> Revision:    02
> Title:       Reauthentication Extension for IKEv2
> Creation_date:    2011-01-14
> WG ID:       Independent Submission
> Number_of_pages: 6
>
> Abstract:
> This document describes an extension to the Internet Key Exchange
> version 2 (IKEv2) protocol that allows an IKEv2 Security Association
> (SA) to be reauthenticated without creating a new IKE SA or new Child
> SAs.
>                                                                              
>
>
> The IETF Secretariat.
>
>
--=_alternative 006D527188257818_=-- From welterk@us.ibm.com Fri Jan 14 16:07:41 2011 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 3E55E3A6CB8 for ; Fri, 14 Jan 2011 16:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 iBRNoVDtp75Z for ; Fri, 14 Jan 2011 16:07:40 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id 46E103A6CB5 for ; Fri, 14 Jan 2011 16:07:40 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0ENvpqX001232 for ; Fri, 14 Jan 2011 16:57:51 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0F09vrB121474 for ; Fri, 14 Jan 2011 17:09:57 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0F09uPK022405 for ; Fri, 14 Jan 2011 17:09:56 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0F09u5R022402 for ; Fri, 14 Jan 2011 17:09:56 -0700 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: BD92F556:D1F97386-88257818:0083CC58; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Fri, 14 Jan 2011 16:09:55 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/14/2011 17:09:56, Serialize complete at 01/14/2011 17:09:56 Content-Type: multipart/alternative; boundary="=_alternative 0000E7B388257819_=" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 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, 15 Jan 2011 00:07:41 -0000 This is a multipart message in MIME format. --=_alternative 0000E7B388257819_= Content-Type: text/plain; charset="US-ASCII" I noticed a minor problem in section 5: "When not using extensible authentication, the peers are authenticated by having each sign (or MAC using a padded shared secret as the key, as described later in this section) a block of data. But the padding is not described later in the section. I will reword the section as follows: "5. Authentication Data for Reauthenticating the IKE SA When not using extensible authentication, the peers are authenticated by having each sign (or MAC using a padded shared secret as the key) a block of data as described in [IKEv2] Section 2.15 except for the following differences: o For the modified IKE_AUTH request, the octets to be signed start with the first octet of the previous Authentication payload sent by the initiator and end with the last octet of that payload. o For the modified IKE_AUTH response, the octets to be signed start with the first octet of the previous Authentication payload sent by the responder and end with the last octet of that payload." Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 0000E7B388257819_= Content-Type: text/html; charset="US-ASCII"
I noticed a minor problem in section 5:
  "When not using extensible authentication, the peers are authenticated
 by having each sign (or MAC using a padded shared secret as the key,
 as described later in this section) a block of data.

But the padding is not described later in the section.  

I will reword the section as follows:
"5. Authentication Data for Reauthenticating the IKE SA

When not using extensible authentication, the peers are authenticated by having each sign (or MAC using a padded shared secret as the key) a block of data as described in [IKEv2] Section 2.15 except for the following differences:  

   o For the modified IKE_AUTH request, the octets to be signed start with the first octet of the previous Authentication payload sent by the initiator and end with the last octet of that payload.  

   o For the modified IKE_AUTH response, the octets to be signed start with the first octet of the previous Authentication payload sent by the responder and end with the last octet of that payload."


Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 0000E7B388257819_=-- From gpoothia@microsoft.com Sun Jan 16 12:58:43 2011 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 7EFDD28C0E1 for ; Sun, 16 Jan 2011 12:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fUo5uiWyqoDm for ; Sun, 16 Jan 2011 12:58:40 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 0A2C128C0DB for ; Sun, 16 Jan 2011 12:58:40 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 16 Jan 2011 13:01:05 -0800 Received: from TK5EX14MBXC118.redmond.corp.microsoft.com ([169.254.9.92]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Sun, 16 Jan 2011 13:01:05 -0800 From: Gaurav Poothia To: "ipsec@ietf.org" Thread-Topic: IKEv2 Diffie Hellman retry logic Thread-Index: Acu1wHs6+T0VnhYRQj61a5elI0clUg== Date: Sun, 16 Jan 2011 21:01:02 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_B69601AD18064F4BBA2D61CA82AEAFA928230CDFTK5EX14MBXC118r_" MIME-Version: 1.0 Cc: Stephen Bensley , Brian Swander , Gabriel Montenegro Subject: [IPsec] IKEv2 Diffie Hellman retry logic 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, 16 Jan 2011 20:58:43 -0000 --_000_B69601AD18064F4BBA2D61CA82AEAFA928230CDFTK5EX14MBXC118r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scenario: When the IKEv2 initiator guesses an incorrect DH group and the re= sponder sends back the DH group hint in INVALID_KE_PAYLOAD notification. Couple of questions around this: On what basis does the responder reject the DH group: 1. Because the best match initiator SA payload proposal (against resp= onder policy) has a different DH group from KE payload 2. Because the responder after looking all the SA payload initiator = proposals with DH group from KE payload finds none of the initiator proposa= ls acceptable 3. Because the responder altogether ignores the initiator proposals (= SA payload) and only checks to see that the DH group in KE payload doesn't = figure in its own policy at all To paraphrase: Case 1 looks like it will have IKEv1 parity in terms of using the best poli= cy match and restarting negotiation if the initial KE guess doesn't match u= p to that. Case 2 will do worse than IKEv1 by not forcing the best policy match but by= proceeding with an inferior and acceptable match will save an extra round = trip. Case 3 is actually non deterministic because the hint is not guaranteed to = work (since other transforms have not been evaluated while choosing hint) Once rejected on what basis does the responder choose the DH group to put i= n the INVALID_KE_PAYLOAD hint (corresponding to above rejection criteria): * For cases 1 & 2: It is the DH group in the initiator SA proposal = that facilitates the best policy match (against responder policy). * For case 3 it the DH group in responder's most preferred proposal= . Thanks --_000_B69601AD18064F4BBA2D61CA82AEAFA928230CDFTK5EX14MBXC118r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scenario: When the IKEv2 initiator guesses an incorr= ect DH group and the responder sends back the DH group hint in INVALID_KE_P= AYLOAD notification.

 

Couple of questions around this:

 

On what basis does the responder reject the DH gr= oup:

1.     &= nbsp; Because the best match initiator SA payload proposa= l (against responder policy) has a different DH group from KE payload<= /o:p>

2.     &= nbsp; Because the responder after looking  all the S= A payload initiator proposals with DH group from KE payload finds none of t= he initiator proposals acceptable

3.     &= nbsp; Because the responder altogether ignores the initia= tor proposals (SA payload) and only checks to see that the DH group in KE p= ayload doesn’t figure in its own policy at all

 

To paraphrase:

Case 1 looks like it will have IKEv1 parity in terms= of using the best policy match and restarting negotiation if the initial K= E guess doesn’t match up to that.

Case 2 will do worse than IKEv1 by not forcing the b= est policy match but by proceeding with an inferior and acceptable match wi= ll save an extra round trip.

Case 3 is actually non deterministic because the hin= t is not guaranteed to work (since other transforms have not been evaluated= while choosing hint)

 

Once rejected on what basis does the responder ch= oose the DH group to put in the INVALID_KE_PAYLOAD hint  (corresponding to above rejection criteria):

·         For cases 1 & 2: It is the DH group in t= he initiator SA proposal that facilitates the best policy match (against re= sponder policy).

·         For case 3 it the DH group in responder̵= 7;s most preferred proposal.

 

Thanks

--_000_B69601AD18064F4BBA2D61CA82AEAFA928230CDFTK5EX14MBXC118r_-- From ynir@checkpoint.com Sun Jan 16 23:51:05 2011 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 9BB093A6EA0 for ; Sun, 16 Jan 2011 23:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.008 X-Spam-Level: X-Spam-Status: No, score=-10.008 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rKtS-HbKXGyf for ; Sun, 16 Jan 2011 23:51:00 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 6AFA93A6E9C for ; Sun, 16 Jan 2011 23:50:59 -0800 (PST) X-CheckPoint: {4D33F57C-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0H7rVg4025885; Mon, 17 Jan 2011 09:53:31 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 17 Jan 2011 09:53:31 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 17 Jan 2011 09:53:31 +0200 From: Yoav Nir To: "'Gaurav Poothia'" , "ipsec@ietf.org" Date: Mon, 17 Jan 2011 09:53:31 +0200 Thread-Topic: IKEv2 Diffie Hellman retry logic Thread-Index: Acu1wHs6+T0VnhYRQj61a5elI0clUgAWpm/Q Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E84990CEE@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_006FEB08D9C6444AB014105C9AEB133F012E84990CEEilex01adche_" MIME-Version: 1.0 Cc: Stephen Bensley , Brian Swander , Gabriel Montenegro Subject: Re: [IPsec] IKEv2 Diffie Hellman retry logic 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, 17 Jan 2011 07:51:05 -0000 --_000_006FEB08D9C6444AB014105C9AEB133F012E84990CEEilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. Yes 2. No. In that case, the correct response in NO PROPOSAL CHOSEN. 3. That is not correct processing. First the responder should match the S= A payload to its own policy. If a match it found, the responder can compare= the DH group in the matched proposal to the one in the KE payload The hint in the INVALID_KE_PAYLOAD notification is the group in the common = proposal. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of G= aurav Poothia Sent: 16 January 2011 23:01 To: ipsec@ietf.org Cc: Stephen Bensley; Brian Swander; Gabriel Montenegro Subject: [IPsec] IKEv2 Diffie Hellman retry logic Scenario: When the IKEv2 initiator guesses an incorrect DH group and the re= sponder sends back the DH group hint in INVALID_KE_PAYLOAD notification. Couple of questions around this: On what basis does the responder reject the DH group: 1. Because the best match initiator SA payload proposal (against resp= onder policy) has a different DH group from KE payload 2. Because the responder after looking all the SA payload initiator = proposals with DH group from KE payload finds none of the initiator proposa= ls acceptable 3. Because the responder altogether ignores the initiator proposals (= SA payload) and only checks to see that the DH group in KE payload doesn't = figure in its own policy at all To paraphrase: Case 1 looks like it will have IKEv1 parity in terms of using the best poli= cy match and restarting negotiation if the initial KE guess doesn't match u= p to that. Case 2 will do worse than IKEv1 by not forcing the best policy match but by= proceeding with an inferior and acceptable match will save an extra round = trip. Case 3 is actually non deterministic because the hint is not guaranteed to = work (since other transforms have not been evaluated while choosing hint) Once rejected on what basis does the responder choose the DH group to put i= n the INVALID_KE_PAYLOAD hint (corresponding to above rejection criteria): * For cases 1 & 2: It is the DH group in the initiator SA proposal = that facilitates the best policy match (against responder policy). * For case 3 it the DH group in responder's most preferred proposal= . Thanks Scanned by Check Point Total Security Gateway. --_000_006FEB08D9C6444AB014105C9AEB133F012E84990CEEilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
  1. Yes
  2. No.=20 In that case, the correct response in NO PROPOSAL CHOSEN.
  3. That=20 is not correct processing. First the responder should match the SA payloa= d to=20 its own policy. If a match it found, the responder can compare the DH gro= up in=20 the matched proposal to the one in the KE payload
 
The=20 hint in the INVALID_KE_PAYLOAD notification is the group in the common=20 proposal.

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Gaurav=20 Poothia
Sent: 16 January 2011 23:01
To:=20 ipsec@ietf.org
Cc: Stephen Bensley; Brian Swander; Gabriel=20 Montenegro
Subject: [IPsec] IKEv2 Diffie Hellman retry=20 logic

Scenario: When the IKEv2 initiator guesses an incorrec= t DH=20 group and the responder sends back the DH group hint in INVALID_KE_PAYLOAD= =20 notification.

 

Couple of questions around this:

 

On what basis does the responder reject the DH=20 group:

1.      = =20 Because the best match initiator SA payload proposa= l=20 (against responder policy) has a different DH group from KE=20 payload

2.      = =20 Because the responder after looking  all the S= A=20 payload initiator proposals with DH group from KE payload finds none of the= =20 initiator proposals acceptable

3.      = =20 Because the responder altogether ignores the initia= tor=20 proposals (SA payload) and only checks to see that the DH group in KE paylo= ad=20 doesn’t figure in its own policy at all

 

To paraphrase:

Case 1 looks like it will have IKEv1 parity in terms o= f using=20 the best policy match and restarting negotiation if the initial KE guess do= esn’t=20 match up to that.

Case 2 will do worse than IKEv1 by not forcing the bes= t=20 policy match but by proceeding with an inferior and acceptable match will s= ave=20 an extra round trip.

Case 3 is actually non deterministic because the hint = is not=20 guaranteed to work (since other transforms have not been evaluated while=20 choosing hint)

 

Once rejected on what basis does the responder choo= se the=20 DH group to put in the INVALID_KE_PAYLOAD hint  (corresponding to = above=20 rejection criteria):

·      &= nbsp; =20 For cases 1 & 2: It is the DH group in t= he=20 initiator SA proposal that facilitates the best policy match (against respo= nder=20 policy).

·      &= nbsp; =20 For case 3 it the DH group in responder̵= 7;s most=20 preferred proposal.

 

Thanks



Scanned by Check Po= int=20 Total Security Gateway.

--_000_006FEB08D9C6444AB014105C9AEB133F012E84990CEEilex01adche_-- From gpoothia@microsoft.com Mon Jan 17 10:39:18 2011 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 542333A6D75 for ; Mon, 17 Jan 2011 10:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Z2Vyq3B8QoTd for ; Mon, 17 Jan 2011 10:39:12 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9C7F53A6E82 for ; Mon, 17 Jan 2011 10:39:12 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jan 2011 10:41:40 -0800 Received: from TK5EX14MBXC118.redmond.corp.microsoft.com ([169.254.9.92]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Mon, 17 Jan 2011 10:41:40 -0800 From: Gaurav Poothia To: Yoav Nir , "ipsec@ietf.org" Thread-Topic: IKEv2 Diffie Hellman retry logic Thread-Index: Acu1wHs6+T0VnhYRQj61a5elI0clUgAWpm/QABZWK0A= Date: Mon, 17 Jan 2011 18:41:40 +0000 Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F012E84990CEE@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F012E84990CEE@il-ex01.ad.checkpoint.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_B69601AD18064F4BBA2D61CA82AEAFA9282322A3TK5EX14MBXC118r_" MIME-Version: 1.0 Cc: Stephen Bensley , Brian Swander , Gabriel Montenegro Subject: Re: [IPsec] IKEv2 Diffie Hellman retry logic 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, 17 Jan 2011 18:39:18 -0000 --_000_B69601AD18064F4BBA2D61CA82AEAFA9282322A3TK5EX14MBXC118r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Yoav. >> First the responder should match the SA payload to its own policy. If a = match it found, the responder can compare the DH group in the matched propo= sal to the one in the KE payload I agree this option seems to make the most sense. From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sunday, January 16, 2011 11:54 PM To: Gaurav Poothia; ipsec@ietf.org Cc: Stephen Bensley; Brian Swander; Gabriel Montenegro Subject: RE: IKEv2 Diffie Hellman retry logic 1. Yes 2. No. In that case, the correct response in NO PROPOSAL CHOSEN. 3. That is not correct processing. First the responder should match the = SA payload to its own policy. If a match it found, the responder can compar= e the DH group in the matched proposal to the one in the KE payload The hint in the INVALID_KE_PAYLOAD notification is the group in the common = proposal. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of G= aurav Poothia Sent: 16 January 2011 23:01 To: ipsec@ietf.org Cc: Stephen Bensley; Brian Swander; Gabriel Montenegro Subject: [IPsec] IKEv2 Diffie Hellman retry logic Scenario: When the IKEv2 initiator guesses an incorrect DH group and the re= sponder sends back the DH group hint in INVALID_KE_PAYLOAD notification. Couple of questions around this: On what basis does the responder reject the DH group: 1. Because the best match initiator SA payload proposal (against resp= onder policy) has a different DH group from KE payload 2. Because the responder after looking all the SA payload initiator = proposals with DH group from KE payload finds none of the initiator proposa= ls acceptable 3. Because the responder altogether ignores the initiator proposals (= SA payload) and only checks to see that the DH group in KE payload doesn't = figure in its own policy at all To paraphrase: Case 1 looks like it will have IKEv1 parity in terms of using the best poli= cy match and restarting negotiation if the initial KE guess doesn't match u= p to that. Case 2 will do worse than IKEv1 by not forcing the best policy match but by= proceeding with an inferior and acceptable match will save an extra round = trip. Case 3 is actually non deterministic because the hint is not guaranteed to = work (since other transforms have not been evaluated while choosing hint) Once rejected on what basis does the responder choose the DH group to put i= n the INVALID_KE_PAYLOAD hint (corresponding to above rejection criteria): * For cases 1 & 2: It is the DH group in the initiator SA proposal = that facilitates the best policy match (against responder policy). * For case 3 it the DH group in responder's most preferred proposal= . Thanks Scanned by Check Point Total Security Gateway. --_000_B69601AD18064F4BBA2D61CA82AEAFA9282322A3TK5EX14MBXC118r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Yoav.

 

>> First the responder should match the SA payload to its = own policy. If a match it found, the responder can compare the DH group in the matched proposal to the one in the KE payload

 

I agree this option seems = to make the most sense.

 

 

From: Yoav Nir= [mailto:ynir@checkpoint.com]
Sent: Sunday, January 16, 2011 11:54 PM
To: Gaurav Poothia; ipsec@ietf.org
Cc: Stephen Bensley; Brian Swander; Gabriel Montenegro
Subject: RE: IKEv2 Diffie Hellman retry logic

 

  1. Yes
    2. No. In that case, the correct response in NO PROPOSA= L CHOSEN.
  2. That is not correct processing. First the responder = should match the SA payload to its own policy. If a match it found, the res= ponder can compare the DH group in the matched proposal to the one in the KE payload
    3. =

 

The hint in the INVALID_KE_PA= YLOAD notification is the group in the common proposal.

 

From:<= /span> ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.or= g] On Behalf Of Gaurav Poothia
Sent: 16 January 2011 23:01
To: ipsec@ietf.org
Cc: Stephen Bensley; Brian Swander; Gabriel Montenegro
Subject: [IPsec] IKEv2 Diffie Hellman retry logic

Scenario: When the IKEv2 initiator guesses an incorr= ect DH group and the responder sends back the DH group hint in INVALID_KE_P= AYLOAD notification.

 

Couple of questions around this:

 

On what basis does the responder reject the DH gr= oup:

1.       Because the best match initiator SA payload proposal (against respon= der policy) has a different DH group from KE payload

2.       Because the responder after looking  all the SA payload initiat= or proposals with DH group from KE payload finds none of the initiator prop= osals acceptable

3.       Because the responder altogether ignores the initiator proposals (SA= payload) and only checks to see that the DH group in KE payload doesn̵= 7;t figure in its own policy at all

 

To paraphrase:

Case 1 looks like it will have IKEv1 parity in terms= of using the best policy match and restarting negotiation if the initial K= E guess doesn’t match up to that.

Case 2 will do worse than IKEv1 by not forcing the b= est policy match but by proceeding with an inferior and acceptable match wi= ll save an extra round trip.

Case 3 is actually non deterministic because the hin= t is not guaranteed to work (since other transforms have not been evaluated= while choosing hint)

 

Once rejected on what basis does the responder ch= oose the DH group to put in the INVALID_KE_PAYLOAD hint  (corresponding to above rejection criteria):

·    &n= bsp;    For cases 1 & 2: It is the DH group in the initiator SA proposal= that facilitates the best policy match (against responder policy).

·    &n= bsp;    For case 3 it the DH group in responder’s most preferred propo= sal.

 

Thanks



Scanned by Check Point Total Security Gateway.

--_000_B69601AD18064F4BBA2D61CA82AEAFA9282322A3TK5EX14MBXC118r_-- From welterk@us.ibm.com Tue Jan 18 16:34:19 2011 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 36A693A6F68 for ; Tue, 18 Jan 2011 16:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HTML_MESSAGE=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 BmKsxmkv9mbP for ; Tue, 18 Jan 2011 16:34:17 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id C39E53A6DB6 for ; Tue, 18 Jan 2011 16:34:17 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0J0W1jn001162 for ; Tue, 18 Jan 2011 17:32:01 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0J0auKo102762 for ; Tue, 18 Jan 2011 17:36:56 -0700 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 p0J0atPW010972 for ; Tue, 18 Jan 2011 17:36:55 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0J0atBw010969 for ; Tue, 18 Jan 2011 17:36:55 -0700 In-Reply-To: <4D2DEAA9.2050301@vpnc.org> References: <4D2DEAA9.2050301@vpnc.org> To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 9EBD79AB:7C3B16B7-8825781C:007E5BA8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Tue, 18 Jan 2011 16:36:49 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/18/2011 17:36:54, Serialize complete at 01/18/2011 17:36:54 Content-Type: multipart/alternative; boundary="=_alternative 00035F608825781D_=" Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection 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, 19 Jan 2011 00:34:19 -0000 This is a multipart message in MIME format. --=_alternative 00035F608825781D_= Content-Type: text/plain; charset="US-ASCII" 1. The last paragraph of section 2 seems to be making an argument against supporting QCD. Would it be possible to add a counterpoint or to reword the paragraph? When I got to the end of the document, I found that section A.4 had the counterpoint I was looking for. Perhaps add a reference to section A.4 from the last paragraph of section 2. 2. In section 4.1 (Notification Format) the TOKEN_SECRET_KEY fields size is given as "(16-128 octets)". I suggest replacing this with "(variable)" so that the specific size requirement only appears in one place (section 5): "Tokens MUST be at least 16 octets long, and no more than 128 octets long, to facilitate storage and transmission." 3. In section 4.3, the text "SHOULD soon initiate an INFORMATIONAL exchange as follows" is vague. How soon is soon? How about: "SHOULD initiate an INFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange as follows". Or, omit "immediately" if that is not strictly necessary. 4. The final paragraph in section 4.3 mentions "key rollover" and "secret QCD keys" but these concepts have not been defined. It seems like this material would fit better in section 5 (Token Generation and Verification) where the cryptographic mechanism for QCD token generation is recommended. 5. Similarly, section 4.5 mentions "periodic rollover of the secret used for token generation" but token generation has not yet been covered. Perhaps a better solution than what I recommended in the prior comment would be to move all of section 5 (i.e. 5 through 5.3) before section 4. That way, token generation would be discussed before any mention of token secrets, keys or rollover in sections 4.1 through 4.5. 6. The first sentence on page 18 is an orphan. 7. In section 11, "contrinuted" should be "contributed". 8. Section A.1 says, "The disadvantage here, is that in IKEv2 an authentication exchange MUST have a piggy-backed Child SA set up." RFC 6023 specifies a childless IKE SA initiation so that sentence is not true for implementations that support RFC 6023. Thanks, Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 00035F608825781D_= Content-Type: text/html; charset="US-ASCII"
1. The last paragraph of section 2 seems to be making an argument against supporting QCD.  Would it be possible to add a counterpoint or to reword the paragraph?  When I got to the end of the document, I found that section A.4 had the counterpoint I was looking for.  Perhaps add a reference to section A.4 from the last paragraph of section 2.
2. In section 4.1 (Notification Format) the TOKEN_SECRET_KEY fields size is given as "(16-128 octets)".  I suggest replacing this with "(variable)" so that the specific size requirement only appears in one place (section 5): "Tokens MUST be at least 16 octets long, and no more than 128 octets long, to facilitate storage and transmission."
3. In section 4.3, the text "SHOULD soon initiate an INFORMATIONAL exchange as follows" is vague.  How soon is soon?  How about: "SHOULD initiate an INFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange as follows".  Or, omit "immediately" if that is not strictly necessary.
4. The final paragraph in section 4.3 mentions "key rollover" and "secret QCD keys" but these concepts have not been defined.  It seems like this material would fit better in section 5 (Token Generation and Verification) where the cryptographic mechanism for QCD token generation is recommended.
5. Similarly, section 4.5 mentions "periodic rollover of the secret used for token generation" but token generation has not yet been covered.  Perhaps a better solution than what I recommended in the prior comment would be to move all of  section 5 (i.e. 5 through 5.3) before section 4.  That way, token generation would be discussed before any mention of token secrets, keys or rollover in sections 4.1 through 4.5.
6. The first sentence on page 18 is an orphan.
7. In section 11, "contrinuted" should be "contributed".
8. Section A.1 says, "The disadvantage here, is that in IKEv2 an authentication exchange MUST have a piggy-backed Child SA set up."  RFC 6023 specifies a childless IKE SA initiation so that sentence is not true for implementations that support RFC 6023.

Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 00035F608825781D_=-- From welterk@us.ibm.com Tue Jan 18 16:41:14 2011 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 0A8613A6DB6 for ; Tue, 18 Jan 2011 16:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HTML_MESSAGE=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 1ttyIgqw-BIG for ; Tue, 18 Jan 2011 16:41:13 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 324AE3A6FDB for ; Tue, 18 Jan 2011 16:41:13 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0J0cvne004751 for ; Tue, 18 Jan 2011 17:38:57 -0700 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 p0J0hps2107654 for ; Tue, 18 Jan 2011 17:43:51 -0700 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 p0J0hpiT013473 for ; Tue, 18 Jan 2011 17:43:51 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0J0hpxl013469 for ; Tue, 18 Jan 2011 17:43:51 -0700 In-Reply-To: References: <4D2DEAA9.2050301@vpnc.org> To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 32D00517:3C18E659-8825781D:0003CCC4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Tue, 18 Jan 2011 16:43:50 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/18/2011 17:43:50, Serialize complete at 01/18/2011 17:43:50 Content-Type: multipart/alternative; boundary="=_alternative 000403ED8825781D_=" Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection 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, 19 Jan 2011 00:41:14 -0000 This is a multipart message in MIME format. --=_alternative 000403ED8825781D_= Content-Type: text/plain; charset="US-ASCII" > 8. Section A.1 says, "The disadvantage here, is that in IKEv2 an > authentication exchange MUST have a piggy-backed Child SA set up." > RFC 6023 specifies a childless IKE SA initiation so that sentence is > not true for implementations that support RFC 6023. I just noticed that the category of RFC 6023 is Experimental so this comment can probably be ignored. Thanks, Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 000403ED8825781D_= Content-Type: text/html; charset="US-ASCII"
> 8. Section A.1 says, "The disadvantage here, is that in IKEv2 an
> authentication exchange MUST have a piggy-backed Child SA set up."  
> RFC 6023 specifies a childless IKE SA initiation so that sentence is
> not true for implementations that support RFC 6023.

I just noticed that the category of RFC 6023 is Experimental so this comment can probably be ignored.

Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 000403ED8825781D_=-- From welterk@us.ibm.com Wed Jan 19 09:18:37 2011 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 D52E728C0E7 for ; Wed, 19 Jan 2011 09:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HTML_MESSAGE=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 sm0K2pqj9MG2 for ; Wed, 19 Jan 2011 09:18:36 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id B4D4428C0DB for ; Wed, 19 Jan 2011 09:18:36 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0JH7hWD017237 for ; Wed, 19 Jan 2011 10:07:43 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JHLEI5101226 for ; Wed, 19 Jan 2011 10:21:15 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0JHLE7p001081 for ; Wed, 19 Jan 2011 10:21:14 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0JHLEkV000929 for ; Wed, 19 Jan 2011 10:21:14 -0700 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 82718D9C:1862AB2B-8825781D:005F16EC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Wed, 19 Jan 2011 09:21:07 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/19/2011 10:21:14, Serialize complete at 01/19/2011 10:21:14 Content-Type: multipart/alternative; boundary="=_alternative 005F51B18825781D_=" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 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, 19 Jan 2011 17:18:37 -0000 This is a multipart message in MIME format. --=_alternative 005F51B18825781D_= Content-Type: text/plain; charset="US-ASCII" I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording shown below. I'd like to ask the working group to accept this as a work item but I am unfamiliar with the process. What next? Thanks, Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) > I noticed a minor problem in section 5: > "When not using extensible authentication, the peers are authenticated > by having each sign (or MAC using a padded shared secret as the key, > as described later in this section) a block of data. > > But the padding is not described later in the section. > > I will reword the section as follows: > "5. Authentication Data for Reauthenticating the IKE SA > > When not using extensible authentication, the peers are > authenticated by having each sign (or MAC using a padded shared > secret as the key) a block of data as described in [IKEv2] Section > 2.15 except for the following differences: > > o For the modified IKE_AUTH request, the octets to be signed > start with the first octet of the previous Authentication payload > sent by the initiator and end with the last octet of that payload. > > o For the modified IKE_AUTH response, the octets to be signed > start with the first octet of the previous Authentication payload > sent by the responder and end with the last octet of that payload." > > > Keith Welter > IBM z/OS Communications Server Developer > 1-415-545-2694 (T/L: 473-2694)_______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 005F51B18825781D_= Content-Type: text/html; charset="US-ASCII"
I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording shown below.  I'd like to ask the working group to accept this as a work item but I am unfamiliar with the process.  What next?

Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

> I noticed a minor problem in section 5:
>   "When not using extensible authentication, the peers are authenticated
>  by having each sign (or MAC using a padded shared secret as the key,
>  as described later in this section) a block of data.
>
> But the padding is not described later in the section.  
>
> I will reword the section as follows:
> "5. Authentication Data for Reauthenticating the IKE SA
>
> When not using extensible authentication, the peers are
> authenticated by having each sign (or MAC using a padded shared
> secret as the key) a block of data as described in [IKEv2] Section
> 2.15 except for the following differences:  
>
>    o For the modified IKE_AUTH request, the octets to be signed
> start with the first octet of the previous Authentication payload
> sent by the initiator and end with the last octet of that payload.  
>
>    o For the modified IKE_AUTH response, the octets to be signed
> start with the first octet of the previous Authentication payload
> sent by the responder and end with the last octet of that payload."
>
>
> Keith Welter
> IBM z/OS Communications Server Developer
> 1-415-545-2694 (T/L: 473-2694)_______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
 --=_alternative 005F51B18825781D_=-- From ynir@checkpoint.com Wed Jan 19 11:35:56 2011 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 407203A71B5 for ; Wed, 19 Jan 2011 11:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.02 X-Spam-Level: X-Spam-Status: No, score=-10.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 6qDFIOX8G4rj for ; Wed, 19 Jan 2011 11:35:52 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 9DD623A7192 for ; Wed, 19 Jan 2011 11:35:51 -0800 (PST) X-CheckPoint: {4D373DB5-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0JJcT8H010969; Wed, 19 Jan 2011 21:38:29 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 19 Jan 2011 21:38:29 +0200 From: Yoav Nir To: Keith Welter Date: Wed, 19 Jan 2011 21:38:27 +0200 Thread-Topic: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 Thread-Index: Acu4EHIgzdoqBXKyQ9uHcquKWJwP0A== Message-ID: <4DC78181-C379-42F6-BC0D-C5485E660743@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: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 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, 19 Jan 2011 19:35:56 -0000 Hi Keith. Generally, the process goes something like this: - You write a draft (done!) - You present it on the mailing list (done!) - Usually, you ask for a time slot to present at a face-to-face meeting (no= t mandatory, but helps). The best is if you present it yourself, but if you= don't plan to attend, someone else could present it for you. - Next the WG chairs ask the group if it wants to accept this. This involve= s: - A rough consensus that this is an idea worth pursuing - Enough people committing to read and review - Enough people willing to contribute text. - Determination of the above is at the discretion of the WG chairs. The adv= antage of presenting at a face-to-face, is that at least the last two quest= ions can be answered there and then. - If there is enough willingness to take on the item, the WG chairs ask the= ADs to add this to the charter. - If the ADs determine that this is a good idea, and has a chance of gettin= g done (a motivated author is one of the requirements), they IESG approves = the recharter - The WG chairs appoint one or more authors for the WG draft. It's not auto= matically you, but usually is, and they might add some more people, especia= lly if they have different ideas. A long process that can take anything from a month to 7 years. See "Wait be= fore WG adoption" in http://www.arkko.com/tools/lifecycle/extremes.html Yoav On Jan 19, 2011, at 7:21 PM, Keith Welter wrote: >=20 > I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording shown= below. I'd like to ask the working group to accept this as a work item bu= t I am unfamiliar with the process. What next?=20 >=20 > Thanks,=20 >=20 > Keith Welter > IBM z/OS Communications Server Developer > 1-415-545-2694 (T/L: 473-2694)=20 >=20 > > I noticed a minor problem in section 5:=20 > > "When not using extensible authentication, the peers are authenticate= d > > by having each sign (or MAC using a padded shared secret as the key, > > as described later in this section) a block of data.=20 > >=20 > > But the padding is not described later in the section. =20 > >=20 > > I will reword the section as follows:=20 > > "5. Authentication Data for Reauthenticating the IKE SA=20 > >=20 > > When not using extensible authentication, the peers are=20 > > authenticated by having each sign (or MAC using a padded shared=20 > > secret as the key) a block of data as described in [IKEv2] Section=20 > > 2.15 except for the following differences: =20 > >=20 > > o For the modified IKE_AUTH request, the octets to be signed=20 > > start with the first octet of the previous Authentication payload=20 > > sent by the initiator and end with the last octet of that payload. =20 > >=20 > > o For the modified IKE_AUTH response, the octets to be signed=20 > > start with the first octet of the previous Authentication payload=20 > > sent by the responder and end with the last octet of that payload."=20 > >=20 > >=20 > > Keith Welter > > IBM z/OS Communications Server Developer > > 1-415-545-2694 (T/L: 473-2694)_________________________________________= ______ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > From welterk@us.ibm.com Wed Jan 19 14:08:26 2011 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 B3D4D28C0EF for ; Wed, 19 Jan 2011 14:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=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 xGee-4kw+yH4 for ; Wed, 19 Jan 2011 14:08:25 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id 5A1E83A6F51 for ; Wed, 19 Jan 2011 14:08:25 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0JLupu6016049 for ; Wed, 19 Jan 2011 14:56:51 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JMAw2F095594 for ; Wed, 19 Jan 2011 15:10:58 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0JMAv0h029335 for ; Wed, 19 Jan 2011 15:10:57 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0JMAvDq029330; Wed, 19 Jan 2011 15:10:57 -0700 In-Reply-To: <4D37577E.8070009@vpnc.org> References: <4D37577E.8070009@vpnc.org> To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 98027C2F:B349FC64-8825781D:007692F2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Wed, 19 Jan 2011 14:10:56 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/19/2011 15:10:56, Serialize complete at 01/19/2011 15:10:57, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/19/2011 15:10:57 Content-Type: multipart/alternative; boundary="=_alternative 0079D8EF8825781D_=" Cc: Yoav Nir , Paul Hoffman Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 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, 19 Jan 2011 22:08:26 -0000 This is a multipart message in MIME format. --=_alternative 0079D8EF8825781D_= Content-Type: text/plain; charset="US-ASCII" Paul Hoffman wrote on 01/19/2011 01:28:30 PM: > On 1/19/11 9:21 AM, Keith Welter wrote: > > > > I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording > > shown below. I'd like to ask the working group to accept this as a work > > item but I am unfamiliar with the process. What next? > > I have Cc'd Yaron on this because he is the co-chair. I have Cc'd Yoav > on this because he replied on-list but missed two very salient points in > his response (it's not in the charter, and there is almost no energy > left in the WG). > > Instead of making this a WG document (which would require a recharter > *and* enough people to give responses), I propose that you simply make > this an Individual Submission to an AD. For that, you just need to > approach the appropriate AD (Sean Turner, in this case) and tell him the > history of the draft. You get extra points if you can say "and I already > have a proposed document shepherd who is credible"; that could be Yaron > or Yoav or me. FWIW, there is no difference between you going through > the WG and Individual Submission for the document being on standards track. > > You could ask the WG if they want to re-charter; my personal preference > would be that you don't. I worry that people will say "yes" and then be > as dead as they are now for our current documents. > > Let Yaron and I know what you think of this prospect. This may be a naive answer, but I'm not opposed to the idea of Individual Submission. I do have some comments/questions: 1. My draft depends on RFC 6023 and cites it as a normative reference. Since I'd like to get my draft on the standards track, does that mean that RFC 6023 needs to get on the standards track too? 2. There is one point I'd still like technical input on, namely the security considerations of signing the previous AUTH payload sent by the host in the modified IKE_AUTH exchange (section 5 of the draft). Yoav suggested this approach, it sounded fine to me, I ran it by a couple of my colleagues (Scott Moonen and David Wierbowski) who thought it sound fine too so I used it in the new draft. I'd feel better if another subject matter expert said, "yes, that is fine." Bonus points if the SME can offer a sentence or two justifying why this mechanism is as secure as the authentication operation that takes place during the initial exchanges. It would be nice to include that information in the security considerations section of my draft. More specifically, RFC 5996 section 2.15 "Authentication of the IKE SA" says, "It is critical to the security of the exchange that each side sign the other side's nonce." Is it necessary to include nonces in the signed data in the proposed modified IKE_AUTH exchange? I don't think so, but since I don't know why it was necessary as part of the signed data in the initial exchanges I don't feel qualified to assert that formally. 3. In practice, is an Individual Submission less likely to be widely adopted than a document that is sponsored by a working group? I realize that is probably a moot point, given the lack of energy in the WG that Paul noted, but I thought I'd ask anyway. Thanks, Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 0079D8EF8825781D_= Content-Type: text/html; charset="US-ASCII"
Paul Hoffman <paul.hoffman@vpnc.org> wrote on 01/19/2011 01:28:30 PM:
> On 1/19/11 9:21 AM, Keith Welter wrote:
> >
> > I submitted draft-welter-ipsecme-ikev2-reauth-03 with the rewording
> > shown below. I'd like to ask the working group to accept this as a work
> > item but I am unfamiliar with the process. What next?
>
> I have Cc'd Yaron on this because he is the co-chair. I have Cc'd Yoav
> on this because he replied on-list but missed two very salient points in
> his response (it's not in the charter, and there is almost no energy
> left in the WG).
>
> Instead of making this a WG document (which would require a recharter
> *and* enough people to give responses), I propose that you simply make
> this an Individual Submission to an AD. For that, you just need to
> approach the appropriate AD (Sean Turner, in this case) and tell him the
> history of the draft. You get extra points if you can say "and I already
> have a proposed document shepherd who is credible"; that could be Yaron
> or Yoav or me. FWIW, there is no difference between you going through
> the WG and Individual Submission for the document being on standards track.
>
> You could ask the WG if they want to re-charter; my personal preference
> would be that you don't. I worry that people will say "yes" and then be
> as dead as they are now for our current documents.
>
> Let Yaron and I know what you think of this prospect.
This may be a naive answer, but I'm not opposed to the idea of Individual Submission.  I do have some comments/questions:
1. My draft depends on RFC 6023 and cites it as a normative reference.  Since I'd like to get my draft on the standards track, does that mean that RFC 6023 needs to get on the standards track too?
2. There is one point I'd still like technical input on, namely the security considerations of signing the previous AUTH payload sent by the host in the modified IKE_AUTH exchange (section 5 of the draft).  Yoav suggested this approach, it sounded fine to me, I ran it by a couple of my colleagues (Scott Moonen and David Wierbowski) who thought it sound fine too so I used it in the new draft.  I'd feel better if another subject matter expert said, "yes, that is fine."  Bonus points if the SME can offer a sentence or two justifying why this mechanism is as secure as the authentication operation that takes place during the initial exchanges.  It would be nice to include that information in the security considerations section of my draft.  More specifically, RFC 5996 section 2.15 "Authentication of the IKE SA" says, "It is critical to the security of the exchange that each side sign the other side's nonce."  Is it necessary to include nonces in the signed data in the proposed modified IKE_AUTH exchange?  I don't think so, but since I don't know why it was necessary as part of the signed data in the initial exchanges I don't feel qualified to assert that formally.
3. In practice, is an Individual Submission less likely to be widely adopted than a document that is sponsored by a working group?  I realize that is probably a moot point, given the lack of energy in the WG that Paul noted, but I thought I'd ask anyway.

Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

--=_alternative 0079D8EF8825781D_=-- From paul.hoffman@vpnc.org Wed Jan 19 16:10:24 2011 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 616FA28C0E4 for ; Wed, 19 Jan 2011 16:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.726 X-Spam-Level: X-Spam-Status: No, score=-101.726 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 DwPa3HlrNhe0 for ; Wed, 19 Jan 2011 16:10:23 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9A3B728C0DE for ; Wed, 19 Jan 2011 16:10:23 -0800 (PST) Received: from MacBook-08.local (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 p0K0D4Qx022284 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 19 Jan 2011 17:13:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D377E0F.9030009@vpnc.org> Date: Wed, 19 Jan 2011 16:13:03 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipsec@ietf.org References: <4D37577E.8070009@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 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, 20 Jan 2011 00:10:24 -0000 On 1/19/11 2:10 PM, Keith Welter wrote: > This may be a naive answer, but I'm not opposed to the idea of > Individual Submission. I do have some comments/questions: > 1. My draft depends on RFC 6023 and cites it as a normative reference. > Since I'd like to get my draft on the standards track, does that mean > that RFC 6023 needs to get on the standards track too? Maybe, but probably not. If you call this out during IETF LC, the IESG can decide whether or not it is allowed. My reading of your draft ("do 6023 but with these changes") does require 6023 to be normative because the reader has to understand 6023, but the fact that 6023 is experimental should not affect your draft because you are giving your own protocol. Others may disagree, though. > 2. There is one point I'd still like technical input on, namely the > security considerations of signing the previous AUTH payload sent by the > host in the modified IKE_AUTH exchange (section 5 of the draft). Yoav > suggested this approach, it sounded fine to me, I ran it by a couple of > my colleagues (Scott Moonen and David Wierbowski) who thought it sound > fine too so I used it in the new draft. I'd feel better if another > subject matter expert said, "yes, that is fine." That's what the informal discussion on this list *and* what IETF Last Call are for. > 3. In practice, is an Individual Submission less likely to be widely > adopted than a document that is sponsored by a working group? No. Notice that RFCs don't say how they got there. > I realize > that is probably a moot point, given the lack of energy in the WG that > Paul noted, but I thought I'd ask anyway. Adoption is much more based on customer demand and the problem that is solved than the origin of the document. From kivinen@iki.fi Thu Jan 20 06:38:36 2011 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 853A93A7125 for ; Thu, 20 Jan 2011 06:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 Q7FdnMfFd768 for ; Thu, 20 Jan 2011 06:38:35 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 59E583A7122 for ; Thu, 20 Jan 2011 06:38:34 -0800 (PST) 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 p0KEf5Nb009094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 16:41:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p0KEf2ve009080; Thu, 20 Jan 2011 16:41:02 +0200 (EET) 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: <19768.18814.516107.222884@fireball.kivinen.iki.fi> Date: Thu, 20 Jan 2011 16:41:02 +0200 From: Tero Kivinen To: Keith Welter In-Reply-To: References: <4D37577E.8070009@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 19 min Cc: ipsec@ietf.org, Yoav Nir , Paul Hoffman Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 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, 20 Jan 2011 14:38:36 -0000 I do not have time to check this document now, as I do have some working group documents that I need to check before getting to this. Keith Welter writes: > This may be a naive answer, but I'm not opposed to the idea of Individual > Submission. I do have some comments/questions: > 1. My draft depends on RFC 6023 and cites it as a normative reference. > Since I'd like to get my draft on the standards track, does that mean that > RFC 6023 needs to get on the standards track too? I would thing experimental would be better status than standard track document. As you point out the RFC 6023 is experimental, as is RFC 4478. I myself would first like to see some real world implementations and use for those (and this) before making them standard track. As you can notice I do not belive that either one of those previous experimental protocols is needed in general in IKEv2, and for example our QuickSec OEM toolkit does not have support for them (and most likely will not have support for them, unless some customer really comes to us and says that they need them and are willing to pay for them :-) I do not really think reauthentication offers anything as in most setups the IKEv2 authentication information is stored in the machine itself and does not require any user interaction (i.e. shared keys in the configuration file, or the private key on the disk). The reauthentication only does mean something in case you are using EAP or private key authentication based on some kind of removable token (smart card etc). If the client is able to store authentication information and replay that when server requires reauthentication then reauthentication does not provide anything. You could simply just ask from the other end "is the user still there", and the other end can say "yes", or "no" without providing any proof. If you are using external token based system like private keys on smartcards then reauthentication gives server a proof that user really did leave the card inserted to the machine. It still does not provide proof that user is still sitting in front of the machine (as most smartcards do keep pin codes etc stored as long as you do not remove the card). If you use EAP with one time passwords or similars where it actually do require user to type in new code every time then user have much harder time to fake the system especially if user cannot get future one time passwords before their time (otherwise he could just type in next n passwords the system might be asking). So the draft should have good rationale explaining in which kind of situations this is actually useful. I do assume that the security model is something that the user is not be trusted, and most likely the user's machine isn't to be trusted either. At least if you plan to go to standard track you better explain why this is needed. As I said I have not read the draft, so it might be you have the text there, so if so very good... > 2. There is one point I'd still like technical input on, namely the > security considerations of signing the previous AUTH payload sent by the > host in the modified IKE_AUTH exchange (section 5 of the draft). Yoav > suggested this approach, it sounded fine to me, I ran it by a couple of my > colleagues (Scott Moonen and David Wierbowski) who thought it sound fine > too so I used it in the new draft. I'd feel better if another subject > matter expert said, "yes, that is fine." Bonus points if the SME can > offer a sentence or two justifying why this mechanism is as secure as the > authentication operation that takes place during the initial exchanges. It > would be nice to include that information in the security considerations > section of my draft. More specifically, RFC 5996 section 2.15 > "Authentication of the IKE SA" says, "It is critical to the security of > the exchange that each side sign the other side's nonce." Is it necessary > to include nonces in the signed data in the proposed modified IKE_AUTH > exchange? I don't think so, but since I don't know why it was necessary > as part of the signed data in the initial exchanges I don't feel qualified > to assert that formally. In the initial authentication the signing of the IKE_SA message proofs that nobody has modified those packets. Note, that it does not sign the IKE_AUTH message, as it is protected by the Integrity Checksum Data field. So the signing of the message data is there just to provide MAC for the first packets which are not MACed normally. The real authentication happens when node signs the other ends nonce and his own MACed ID. Read the SIGMA documentation for more details: [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", Advances in Cryptography - CRYPTO 2003 Proceedings LNCS 2729, 2003, . > 3. In practice, is an Individual Submission less likely to be widely > adopted than a document that is sponsored by a working group? I realize > that is probably a moot point, given the lack of energy in the WG that > Paul noted, but I thought I'd ask anyway. Protocols get adopted if there is real use for them. Whether it is standard track, informational, experimental, WG document or individual submission does not really matter. Hopefully the standard track documents get bit more widely implemented than experimental documents, but that is not because of their status, but because protocols which seem to have real use are more often pushed to be on standard track. -- kivinen@iki.fi From welterk@us.ibm.com Thu Jan 20 15:53:29 2011 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 C4ED93A6877 for ; Thu, 20 Jan 2011 15:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HTML_MESSAGE=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 WTo5ce5UeXlG for ; Thu, 20 Jan 2011 15:53:28 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id C7FB53A687D for ; Thu, 20 Jan 2011 15:53:27 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0KNfp5S000785 for ; Thu, 20 Jan 2011 16:41:51 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0KNu92k176578 for ; Thu, 20 Jan 2011 16:56:09 -0700 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 p0KNu9Ld018736 for ; Thu, 20 Jan 2011 16:56:09 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p0KNu9hm018733; Thu, 20 Jan 2011 16:56:09 -0700 In-Reply-To: <19768.18814.516107.222884@fireball.kivinen.iki.fi> References: <4D37577E.8070009@vpnc.org> <19768.18814.516107.222884@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 27D379EF:8E88D48C-8825781E:00763661; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Thu, 20 Jan 2011 15:56:07 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 01/20/2011 16:56:08, Serialize complete at 01/20/2011 16:56:08 Content-Type: multipart/alternative; boundary="=_alternative 00837A5D8825781E_=" Cc: ipsec@ietf.org, Yoav Nir , Paul Hoffman Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02 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, 20 Jan 2011 23:53:29 -0000 This is a multipart message in MIME format. --=_alternative 00837A5D8825781E_= Content-Type: text/plain; charset="US-ASCII" Tero Kivinen wrote on 01/20/2011 06:41:02 AM: > I do not really think reauthentication offers anything as in most > setups the IKEv2 authentication information is stored in the machine > itself and does not require any user interaction (i.e. shared keys in > the configuration file, or the private key on the disk). > > The reauthentication only does mean something in case you are using > EAP or private key authentication based on some kind of removable > token (smart card etc). If the client is able to store authentication > information and replay that when server requires reauthentication then > reauthentication does not provide anything. You could simply just ask > from the other end "is the user still there", and the other end can > say "yes", or "no" without providing any proof. > > If you are using external token based system like private keys on > smartcards then reauthentication gives server a proof that user really > did leave the card inserted to the machine. It still does not provide > proof that user is still sitting in front of the machine (as most > smartcards do keep pin codes etc stored as long as you do not remove > the card). > > If you use EAP with one time passwords or similars where it actually > do require user to type in new code every time then user have much > harder time to fake the system especially if user cannot get future > one time passwords before their time (otherwise he could just type in > next n passwords the system might be asking). > > So the draft should have good rationale explaining in which kind of > situations this is actually useful. I do assume that the security > model is something that the user is not be trusted, and most likely > the user's machine isn't to be trusted either. > > At least if you plan to go to standard track you better explain why > this is needed. > > As I said I have not read the draft, so it might be you have the text > there, so if so very good... The draft does list some problems with reauthentication as defined in RFC 5996 but it doesn't say why one might do reauthentication in the first place. RFC 5996 says, "Although rekeying the IKE SA may be important in some environments, reauthentication (the verification that the parties still have access to the long-term credentials) is often more important." One use case that occurs to me is detecting that the peer's certificate has been revoked. If you just rekey the IKE SA forever you would not detect that. > > > 2. There is one point I'd still like technical input on, namely the > > security considerations of signing the previous AUTH payload sent by the > > host in the modified IKE_AUTH exchange (section 5 of the draft). Yoav > > suggested this approach, it sounded fine to me, I ran it by a couple of my > > colleagues (Scott Moonen and David Wierbowski) who thought it sound fine > > too so I used it in the new draft. I'd feel better if another subject > > matter expert said, "yes, that is fine." Bonus points if the SME can > > offer a sentence or two justifying why this mechanism is as secure as the > > authentication operation that takes place during the initial exchanges. It > > would be nice to include that information in the security considerations > > section of my draft. More specifically, RFC 5996 section 2.15 > > "Authentication of the IKE SA" says, "It is critical to the security of > > the exchange that each side sign the other side's nonce." Is it necessary > > to include nonces in the signed data in the proposed modified IKE_AUTH > > exchange? I don't think so, but since I don't know why it was necessary > > as part of the signed data in the initial exchanges I don't feel qualified > > to assert that formally. > > In the initial authentication the signing of the IKE_SA message proofs > that nobody has modified those packets. Note, that it does not sign > the IKE_AUTH message, as it is protected by the Integrity Checksum > Data field. So the signing of the message data is there just to > provide MAC for the first packets which are not MACed normally. > > The real authentication happens when node signs the other ends nonce > and his own MACed ID. > > Read the SIGMA documentation for more details: > > [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to > Authenticated Diffie-Hellman and its Use in the IKE > Protocols", Advances in Cryptography - CRYPTO 2003 > Proceedings LNCS 2729, 2003, www.informatik.uni-trier.de/~ley/db/conf/crypto/ > crypto2003.html>. Thanks, I'll take a look at that. > > > 3. In practice, is an Individual Submission less likely to be widely > > adopted than a document that is sponsored by a working group? I realize > > that is probably a moot point, given the lack of energy in the WG that > > Paul noted, but I thought I'd ask anyway. > > Protocols get adopted if there is real use for them. Whether it is > standard track, informational, experimental, WG document or individual > submission does not really matter. > > Hopefully the standard track documents get bit more widely implemented > than experimental documents, but that is not because of their status, > but because protocols which seem to have real use are more often > pushed to be on standard track. > -- > kivinen@iki.fi --=_alternative 00837A5D8825781E_= Content-Type: text/html; charset="US-ASCII"
Tero Kivinen <kivinen@iki.fi> wrote on 01/20/2011 06:41:02 AM:
> I do not really think reauthentication offers anything as in most
> setups the IKEv2 authentication information is stored in the machine
> itself and does not require any user interaction (i.e. shared keys in
> the configuration file, or the private key on the disk).
>
> The reauthentication only does mean something in case you are using
> EAP or private key authentication based on some kind of removable
> token (smart card etc). If the client is able to store authentication
> information and replay that when server requires reauthentication then
> reauthentication does not provide anything. You could simply just ask
> from the other end "is the user still there", and the other end can
> say "yes", or "no" without providing any proof.
>
> If you are using external token based system like private keys on
> smartcards then reauthentication gives server a proof that user really
> did leave the card inserted to the machine. It still does not provide
> proof that user is still sitting in front of the machine (as most
> smartcards do keep pin codes etc stored as long as you do not remove
> the card).
>
> If you use EAP with one time passwords or similars where it actually
> do require user to type in new code every time then user have much
> harder time to fake the system especially if user cannot get future
> one time passwords before their time (otherwise he could just type in
> next n passwords the system might be asking).
>
> So the draft should have good rationale explaining in which kind of
> situations this is actually useful. I do assume that the security
> model is something that the user is not be trusted, and most likely
> the user's machine isn't to be trusted either.
>
> At least if you plan to go to standard track you better explain why
> this is needed.
>
> As I said I have not read the draft, so it might be you have the text
> there, so if so very good...
The draft does list some problems with reauthentication as defined in RFC 5996 but it doesn't say why one might do reauthentication in the first place.  RFC 5996 says, "Although rekeying the IKE SA may be important in some environments, reauthentication (the verification that the parties still have access to the long-term credentials) is often more important."  One use case that occurs to me is detecting that the peer's certificate has been revoked.  If you just rekey the IKE SA forever you would not detect that.  

>
> > 2. There is one point I'd still like technical input on, namely the
> > security considerations of signing the previous AUTH payload sent by the
> > host in the modified IKE_AUTH exchange (section 5 of the draft).  Yoav
> > suggested this approach, it sounded fine to me, I ran it by a couple of my
> > colleagues (Scott Moonen and David Wierbowski) who thought it sound fine
> > too so I used it in the new draft.  I'd feel better if another subject
> > matter expert said, "yes, that is fine."  Bonus points if the SME can
> > offer a sentence or two justifying why this mechanism is as secure as the
> > authentication operation that takes place during the initial exchanges. It
> > would be nice to include that information in the security considerations
> > section of my draft.  More specifically, RFC 5996 section 2.15
> > "Authentication of the IKE SA" says, "It is critical to the security of
> > the exchange that each side sign the other side's nonce."  Is it necessary
> > to include nonces in the signed data in the proposed modified IKE_AUTH
> > exchange?  I don't think so, but since I don't know why it was necessary
> > as part of the signed data in the initial exchanges I don't feel qualified
> > to assert that formally.
>
> In the initial authentication the signing of the IKE_SA message proofs
> that nobody has modified those packets. Note, that it does not sign
> the IKE_AUTH message, as it is protected by the Integrity Checksum
> Data field. So the signing of the message data is there just to
> provide MAC for the first packets which are not MACed normally.
>
> The real authentication happens when node signs the other ends nonce
> and his own MACed ID.
>
> Read the SIGMA documentation for more details:
>
>    [SIGMA]    H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
>               Authenticated Diffie-Hellman and its Use in the IKE
>               Protocols", Advances in Cryptography - CRYPTO 2003
>               Proceedings LNCS 2729, 2003, <http://
>               www.informatik.uni-trier.de/~ley/db/conf/crypto/
>               crypto2003.html>.
Thanks, I'll take a look at that.

>
> > 3. In practice, is an Individual Submission less likely to be widely
> > adopted than a document that is sponsored by a working group?  I realize
> > that is probably a moot point, given the lack of energy in the WG that
> > Paul noted, but I thought I'd ask anyway.
>
> Protocols get adopted if there is real use for them. Whether it is
> standard track, informational, experimental, WG document or individual
> submission does not really matter.
>
> Hopefully the standard track documents get bit more widely implemented
> than experimental documents, but that is not because of their status,
> but because protocols which seem to have real use are more often
> pushed to be on standard track.
> --
> kivinen@iki.fi
 --=_alternative 00837A5D8825781E_=-- From paul.hoffman@vpnc.org Mon Jan 24 07:43:05 2011 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 43D423A6AEA for ; Mon, 24 Jan 2011 07:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.732 X-Spam-Level: X-Spam-Status: No, score=-101.732 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 D+6DHbiybd8q for ; Mon, 24 Jan 2011 07:43:04 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9734B3A6AE2 for ; Mon, 24 Jan 2011 07:43:04 -0800 (PST) Received: from MacBook-08.local (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 p0OFjwFY058782 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 24 Jan 2011 08:45:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3D9EB6.9090202@vpnc.org> Date: Mon, 24 Jan 2011 07:45:58 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] NUDGE: WG Last Call on draft-ietf-ipsecme-failure-detection 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, 24 Jan 2011 15:43:05 -0000 There has been very little discussion on this document in the past two weeks. Note that the WG LC in the note below ends on this Wednesday, the 26th. ================================================================== Greetings again. This starts the two-week WG Last Call on draft-ietf-ipsecme-failure-detection, currently the -03 draft. There has been very little comment on this document lately, but please not that issue #202 (see ) is still open. Also note that our virtual interim meeting, which is meant to focus on this document, happens the day before this WG LC closes. If there continues to be little comment on the document or on issue #202, that will be a very short meeting. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Jan 24 07:43:14 2011 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 EB23B3A6AEB for ; Mon, 24 Jan 2011 07:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.733 X-Spam-Level: X-Spam-Status: No, score=-101.733 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 GHnLQ80VDD6r for ; Mon, 24 Jan 2011 07:43:13 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 79D173A6AE5 for ; Mon, 24 Jan 2011 07:43:13 -0800 (PST) Received: from MacBook-08.local (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 p0OFk7IG058794 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 24 Jan 2011 08:46:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3D9EBF.4000909@vpnc.org> Date: Mon, 24 Jan 2011 07:46:07 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] NUDGE: IPSECME WG Virtual Interim Meeting, January 25, 2010 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, 24 Jan 2011 15:43:15 -0000 This is just a reminder of tomorrow's meeting. Given the lack of traffic on the mailing list for the WG LC, I suspect that this will be a *very* short meeting. ====================================================================== The IPsecME WG will have a virtual interim WG meeting on Tuesday January 25, 16:00 GMT (21:30 Kolkata, 18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for up to 2 hours. The agenda is to discuss any remaining issues with draft-ietf-ipsecme-failure-detection. The meeting will be held as a conference call using a VoIP conference bridge and posted slides (if needed). Technical details here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls. From paul.hoffman@vpnc.org Tue Jan 25 08:26:19 2011 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 A11413A680D for ; Tue, 25 Jan 2011 08:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.99 X-Spam-Level: X-Spam-Status: No, score=-100.99 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, 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 KxrVLqJzx0dR for ; Tue, 25 Jan 2011 08:26:17 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 730863A680F for ; Tue, 25 Jan 2011 08:26:17 -0800 (PST) Received: from MacBook-08.local (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 p0PGTEP3034720 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 09:29:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3EFA5A.5080106@vpnc.org> Date: Tue, 25 Jan 2011 08:29:14 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [IPsec] Proposed minutes of this morning's virtual interim 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: Tue, 25 Jan 2011 16:26:19 -0000 As expected, it was short. If any of the participants have changes to the minutes, let me know in the next two days. --Paul Hoffman IPsecME WG Minutes of the Virtual Interim Meeting 2011-01-25 1600 GMT Attendees: David Wierbowski Matt Lepinski Paul Hoffman Richard Graveman Scott Moonen Sheila Frankel Tero Kivinen Yaron Sheffer Yoav Nir Main topic: WG LC for draft-ietf-ipsecme-failure-detection-03 Yoav: open issue is about specific cluster configuration Do we care about this? Pratima and Frederic were the ones who brought this scenario Paul: Will probably accept suggestion from David Wierbowski and Scott Moonen to combine 9.2 and 9.4  ...unless anything is heard in the next 36 hours by the end of WG LC General discussion that combining 9.2 and 9.4 will solve the open issue Tero: We need to look in 5 as well, since some of it is there for 9.4 Paul: That sounds good Next up for the WG: draft-ietf-ipsecme-ipsecha-protocol-02 WG LC will start soon We might have another virtual interim during WG LC for it Meeting was adjourned at 1615 PST From paul.hoffman@vpnc.org Thu Jan 27 08:39:25 2011 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 ABDED28C143 for ; Thu, 27 Jan 2011 08:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, 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 ndr3xahHmF1E for ; Thu, 27 Jan 2011 08:39:25 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id EB4F128C145 for ; Thu, 27 Jan 2011 08:39:12 -0800 (PST) Received: from MacBook-08.local (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 p0RGgGip063190 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Jan 2011 09:42:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D41A068.6070108@vpnc.org> Date: Thu, 27 Jan 2011 08:42:16 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipsec@ietf.org References: <4D2DEAA9.2050301@vpnc.org> In-Reply-To: <4D2DEAA9.2050301@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection 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, 27 Jan 2011 16:39:25 -0000 This message closed out the WG LC. There remains one open issue, #202. Based on Scott Moonen's suggestion, he and David Weirbowski will propose wording for combining sections 9.2 and 9.4 into a single discussion that will close this issue. They can bring this proposal to the mailing list and, assuming there is general agreement, the authors will put out a final version with it in it and we can move the document to our Area Director. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Thu Jan 27 13:44:07 2011 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 C36213A69D7 for ; Thu, 27 Jan 2011 13:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.03 X-Spam-Level: X-Spam-Status: No, score=-10.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 R7lM07TlEDeP for ; Thu, 27 Jan 2011 13:44:07 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id A390A3A6A59 for ; Thu, 27 Jan 2011 13:44:06 -0800 (PST) X-CheckPoint: {4D41E7DE-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0RLl965030206; Thu, 27 Jan 2011 23:47:09 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 27 Jan 2011 23:47:08 +0200 From: Yoav Nir To: Paul Hoffman Date: Thu, 27 Jan 2011 23:47:07 +0200 Thread-Topic: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection Thread-Index: Acu+a77l+tCvN1QiTl+1DR8Y4GE2Rw== Message-ID: <3FE3102A-CE5A-464E-A2CD-19781643829B@checkpoint.com> References: <4D2DEAA9.2050301@vpnc.org> <4D41A068.6070108@vpnc.org> In-Reply-To: <4D41A068.6070108@vpnc.org> 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] WG Last Call on draft-ietf-ipsecme-failure-detection 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, 27 Jan 2011 21:44:07 -0000 I'd like to also point out that Scott and Keith have pointed out some nits = in the spec (on the 12th and 19th of January respectively), which will also= be included in the final version. Yoav On Jan 27, 2011, at 6:42 PM, Paul Hoffman wrote: > This message closed out the WG LC. There remains one open issue, #202.=20 > Based on Scott Moonen's suggestion, he and David Weirbowski will propose= =20 > wording for combining sections 9.2 and 9.4 into a single discussion that= =20 > will close this issue. They can bring this proposal to the mailing list=20 > and, assuming there is general agreement, the authors will put out a=20 > final version with it in it and we can move the document to our Area=20 > Director. >=20 > --Paul Hoffman, Director > --VPN Consortium From ynir@checkpoint.com Sat Jan 29 23:57:31 2011 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 0AFF53A6A7A for ; Sat, 29 Jan 2011 23:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.04 X-Spam-Level: X-Spam-Status: No, score=-10.04 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7WAcnsA7xd0i for ; Sat, 29 Jan 2011 23:57:29 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 7AB1E3A6A6C for ; Sat, 29 Jan 2011 23:57:28 -0800 (PST) X-CheckPoint: {4D451AA6-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0U80bia006244; Sun, 30 Jan 2011 10:00:37 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Sun, 30 Jan 2011 10:00:37 +0200 From: Yoav Nir To: Keith Welter Date: Sun, 30 Jan 2011 10:00:38 +0200 Thread-Topic: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection Thread-Index: AcvAU8amDxmVxyHySNedV28XFxQDtg== Message-ID: <45DC1BFE-6273-46F3-83F8-759CC1CAAA85@checkpoint.com> References: <4D2DEAA9.2050301@vpnc.org> 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_45DC1BFE627346F383F8759CC1CAAA85checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection 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, 30 Jan 2011 07:57:31 -0000 --_000_45DC1BFE627346F383F8759CC1CAAA85checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Keith. Thanks for the comments. My responses inline. On Jan 19, 2011, at 2:36 AM, Keith Welter wrote: 1. The last paragraph of section 2 seems to be making an argument against s= upporting QCD. Would it be possible to add a counterpoint or to reword the= paragraph? When I got to the end of the document, I found that section A.= 4 had the counterpoint I was looking for. Perhaps add a reference to secti= on A.4 from the last paragraph of section 2. OK. How about: Some existing IKEv2 implementations already do that (i.e., both shorten timeouts or limit number of retries) based on these kind of hints and also start liveness checks quickly after the other end goes silent. However, see Appendix A.4 for a discussion of why this may not be enough. 2. In section 4.1 (Notification Format) the TOKEN_SECRET_KEY fields size is= given as "(16-128 octets)". I suggest replacing this with "(variable)" so= that the specific size requirement only appears in one place (section 5): = "Tokens MUST be at least 16 octets long, and no more than 128 octets long, = to facilitate storage and transmission." OK. 3. In section 4.3, the text "SHOULD soon initiate an INFORMATIONAL exchange= as follows" is vague. How soon is soon? How about: "SHOULD initiate an I= NFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange as fol= lows". Or, omit "immediately" if that is not strictly necessary. OK, and I went with "immediately". If the initiator doesn't do it, QCD does= not work. 4. The final paragraph in section 4.3 mentions "key rollover" and "secret Q= CD keys" but these concepts have not been defined. It seems like this mate= rial would fit better in section 5 (Token Generation and Verification) wher= e the cryptographic mechanism for QCD token generation is recommended. I disagree with this. Section 4 has all the information about using the not= ification payload. How about if I add a pointer like this: The INFORMATIONAL exchange described in this section can also be used if QCD tokens need to be replaced due to a key rollover. However, since token takers are required to verify at least 4 QCD tokens, this is only necessary if secret QCD keys are rolled over more than four times as often as IKE SAs are rekeyed. See Section 5.1 for an example method that uses secret keys which may require rollover. 5. Similarly, section 4.5 mentions "periodic rollover of the secret used fo= r token generation" but token generation has not yet been covered. Perhaps= a better solution than what I recommended in the prior comment would be to= move all of section 5 (i.e. 5 through 5.3) before section 4. That way, t= oken generation would be discussed before any mention of token secrets, key= s or rollover in sections 4.1 through 4.5. See last remark. 6. The first sentence on page 18 is an orphan. That's just how the xml2rfc utility formats it. When (and if) it gets publi= shed, the RFC editor takes care of these stylistic issues. 7. In section 11, "contrinuted" should be "contributed". Will be fixed in -04. 8. Section A.1 says, "The disadvantage here, is that in IKEv2 an authentica= tion exchange MUST have a piggy-backed Child SA set up." RFC 6023 specifie= s a childless IKE SA initiation so that sentence is not true for implementa= tions that support RFC 6023. True, but since RFC 6023 is experimental, I would like to leave this senten= ce. Also, the important part is the next paragraph, which says that sometim= es setting up a new IKE SA is not possible for the former responder. Thanks, Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) Scanned by Check Point Total Security Gateway. --_000_45DC1BFE627346F383F8759CC1CAAA85checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Keith. 

Thanks for the comments. My responses inline.

<= div>On Jan 19, 2011, at 2:36 AM, Keith Welter wrote:


1. The last paragraph of section 2= seems to be making an argument against supporting QCD.  Would it be possible to add a counterpoint or to reword the paragraph?  When I got to the end of the document, I found that section A.4 had the counterpoint I was looking for.  Perhaps add a reference to section A.4 from the last paragraph of section 2.

OK. How about:

 &nb= sp; Some existing IKEv2 implementations already do that (i.e., both
   shorten timeouts or limit number of retries) based on these= kind of
   hints and also start liveness checks quickl= y after the other end goes
   silent.  However, se= e Appendix A.4 for a discussion of why this may
   not = be enough.

2. In section 4.1 (Notification Format) the TOKEN_SECRET_KEY fields size is given as "(16-128 octets)".  I suggest replacing this with "(variable)" so that the specific size requirement only appears in one place (section 5): "Tokens MUST be at least 16 octets long, and no more than 128 octets long, to facil= itate storage and transmission."

OK.

3. In section 4.3, the text "SHOULD soon initiate an INFORMATIONAL exchange as follows" is vague.  How soon is soon?  How about: "SHOULD initiate an INFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange as follows".  Or, omit "immediately" if that is not strictly necessary.

OK, and I went with "immediately". If the i= nitiator doesn't do it, QCD does not work.

4. The final paragraph in se= ction 4.3 mentions "key rollover" and "secret QCD keys" but these concepts have not been defined.  It seems like this material would fit better in section 5 (Token Generation and Verification) where the crypt= ographic mechanism for QCD token generation is recommended.

I disagree with this. Section 4 has al= l the information about using the notification payload. How about if I add = a pointer like this:

   The INFORMA= TIONAL exchange described in this section can also be used
 =   if QCD tokens need to be replaced due to a key rollover.  Howev= er,
   since token takers are required to verify at lea= st 4 QCD tokens, this
   is only necessary if secret QC= D keys are rolled over more than four
   times as often= as IKE SAs are rekeyed.  See Section 5.1 for an
  = ; example method that uses secret keys which may require rollover.


5. Similarly, section 4.5 mentions "periodic rollover of the secret used for token generation" but token generation has not yet been covered.  Perhaps a better solution than what I recom= mended in the prior comment would be to move all of  section 5 (i.e. 5 throug= h 5.3) before section 4.  That way, token generation would be discussed before any mention of token secrets, keys or rollover in sections 4.1 throu= gh 4.5.

See last remark.

6. The first sentence on= page 18 is an orphan.

That's just how the xml2rfc utility fo= rmats it. When (and if) it gets published, the RFC editor takes care of the= se stylistic issues.

7. In section 11, "contrinuted" should be "contributed".

Will be fixed in -04.

8. Section A.1 says= , "The disadvantage here, is that in IKEv2 an authentication exchange MUST have a piggy-backed Child SA set up."  RFC 6023 specifies a childless IKE SA initiation so that sentence is not true for implementations that support RFC 6023.

True, but since RFC 6023 is experimental, I= would like to leave this sentence. Also, the important part is the next pa= ragraph, which says that sometimes setting up a new IKE SA is not possible = for the former responder.


Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

Scanned by Check Point Total Security Gateway.

<ATT00001..txt>

= --_000_45DC1BFE627346F383F8759CC1CAAA85checkpointcom_-- From ynir@checkpoint.com Sat Jan 29 23:57:34 2011 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 8D36A3A6B25 for ; Sat, 29 Jan 2011 23:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.05 X-Spam-Level: X-Spam-Status: No, score=-10.05 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WDqcp1Ec5Ga0 for ; Sat, 29 Jan 2011 23:57:32 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 18FF43A6A6C for ; Sat, 29 Jan 2011 23:57:30 -0800 (PST) X-CheckPoint: {4D451AA9-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0U80ff4006262; Sun, 30 Jan 2011 10:00:41 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Sun, 30 Jan 2011 10:00:41 +0200 From: Yoav Nir To: Scott C Moonen Date: Sun, 30 Jan 2011 10:00:42 +0200 Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt Thread-Index: AcvAU8kZTIPicm2yTCWLEIO99oyK4g== Message-ID: <8F3501F2-B204-40E3-9973-9BA673D8FF86@checkpoint.com> References: <20110110074502.22466.22300.idtracker@localhost> 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_8F3501F2B20440E399739BA673D8FF86checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.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, 30 Jan 2011 07:57:34 -0000 --_000_8F3501F2B20440E399739BA673D8FF86checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott. Thanks for your comments. My replies inline. On Jan 12, 2011, at 10:45 PM, Scott C Moonen wrote: Comments on the draft, mostly editorial in nature: (1) There are still some blockquotes that start with excessive first-line i= ndents, eg., the three quotes on page 5. Those are intentional. They quote from the RFC, so I copied them line by li= ne. (2) Page 5, should add comma after "system" in "Reboot, depending on the sy= stem." Will be fixed in -04. (3) Page 5, should pluralize "implementation" in "IKEv2 implementation can = detect." Will be fixed in -04. (4) Page 5, should remove "the" in "rules given in the section." Will be fixed in -04. (5) Page 6, correct "even has change" to "even has a chance." Will be fixed in -04. (6) Page 6, change comma to semicolon in "immediately, in those cases." Will be fixed in -04. (7) Page 6, suggest improving sentence beginning "Note, that" to read "Note= that the IKEv2 specification specifically gives no guidance for the number= of retries or the length of timeouts, as these do not affect interoperabil= ity." Will be fixed in -04. (8) Page 6, suggest changing "messages as hints that will shorten" to read = "messages to shorten." Will be fixed in -04. (9) Global, need commas after "i.e." Will be fixed in -04. (10) Page 6, change "that kind of hints" to either "this kind of hint" or "= these kinds of hints." Will be fixed in -04. (11) Page 7, pluralize first word in "Implementation that are not token tak= ers." Will be fixed in -04. (12) Section 4.1, should we specify that the critical bit is set to 0? I think not, because that is true of any notify payload (13) Page 8, the last line is an orphan. Not sure what you mean. It says "In any case, the lack of a QCD_TOKEN notif= ication MUST NOT be taken" and then continues on the next page. (14) Section 4.2 says the payload "MUST follow . . . and precede . . ." In = general I think the IKEv2 specs have tried to say SHOULD for ordering consi= derations; should we do so here? Agree that we shouldn't. RFC5996 specifically says that order doesn't matte= r. If nobody objects, I'll change it to a lower-case "should". (15) Section 4.3 says "SHOULD send a new ticket." I think we mean to say "Q= CD_TOKEN notification" instead of "ticket." No. That sentence is about session resumption (RFC 5723), where they do use= "tickets". The second sentence talks about tokens: For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket within the protected payload of the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. (16) Section 4.5, is it correct to denote the unprotected message as a "req= uest" in the flow diagrams? I think we were careful in RFC 5996 to denote s= tandalone messages as informational messages rather than informational requ= ests. OK. I'll change it to "message" (17) Section 7, change "new IKE SA consume" to "new IKE SA to consume." OK. (18) Section 7, suggest changing "re-establishment should occur" to either = "would occur" or "will occur." Agree, but I will solve it by moving the whole paragraph to the present ten= se: Session resumption, specified in [RFC5723], allows the setting up of a new IKE SA to consume less computing resources. This is particularly useful in the case of a remote access gateway that has many tunnels. A failure of such a gateway requires all these many remote access clients to establish an IKE SA either with the rebooted gateway or with a backup. This tunnel re-establishment occurs within a short period of time, creating a burden on the remote access gateway. Session resumption addresses this problem by having the clients store an encrypted derivative of the IKE SA for quick re- establishment. (19) Section 8.1, suggest changing "inter-domain VPN gateway" to either add= "an" before it or pluralize "gateway." Since the other bullet points are pluralized, I'll go with the former. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen Internet-Drafts---01/10/2011 02:48:33 AM---A New Internet-Draf= t is available from the on-line Internet-Drafts directories. This draft is = a work From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ipsec@ietf.org Date: 01/10/2011 02:48 AM Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt Sent by: ipsec-bounces@ietf.org ________________________________ A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wor= king Group of the IETF. Title : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-03.txt Pages : 23 Date : 2011-01-09 This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-03= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-det= ection-03.txt_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_8F3501F2B20440E399739BA673D8FF86checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott.

Thanks for your comments. My replies inline.

On Jan 12, 2011, at 10:45 PM, Scott C Moonen wrote:

Comments o= n the draft, mostly editorial in nature:

(1) There are still some blockquotes that start with excessive first-line i= ndents, eg., the three quotes on page 5.

Tho= se are intentional. They quote from the RFC, so I copied them line by line.=

(2) Page 5, should add comma after "system" in "Reboot, depending on the sy= stem."

Will be fixed in -04.

(3) Page 5, should pluralize "implementation" in "IKEv2 implementation can = detect."

Will be fixed in -04.

(4) Page 5, should remove "the" in "rules given in the section."

Will be fixed in -04.

(5) Page 6, correct "even has change" to "even has a chance."=

Will be fixed in -04.

(6) Page 6, change comma to semicolon in "immediately, in those cases."
=

Will be fixed in -04.
<= div>

(7) Page 6, suggest improving sentence beginning "Note, that" to read "Note= that the IKEv2 specification specifically gives no guidance for the number= of retries or the length of timeouts, as these do not affect interoperabil= ity."

Will be fixed in -04.

(8) Page 6, suggest changing "messages as hints that will shorten" to read = "messages to shorten."

Will be fixed in -04.
<= blockquote type=3D"cite">

(9) Global, need commas after "i.e."

Will be fixe= d in -04.

(10) Page 6, change "that kind of hints" to either "this kind of hint" or "= these kinds of hints."

Will be fixed in -04.
<= blockquote type=3D"cite">

(11) Page 7, pluralize first word in "Implementation that are not token tak= ers."

Will be fixed in -04.

(12) Section 4.1, should we specify that the critical bit is set to 0?
<= /p>

I think not, because that is true of any notify paylo= ad

(13) Page 8, the last line is an orphan.

Not sure= what you mean. It says "In any case, the lack of a QCD_TOKEN notification = MUST NOT be taken" and then continues on the next page.

(14) Section 4.2 says the payload "MUST follow . . . and precede . . ." In= general I think the IKEv2 specs have tried to say SHOULD for ordering cons= iderations; should we do so here?

Agree that we s= houldn't. RFC5996 specifically says that order doesn't matter. If nobody ob= jects, I'll change it to a lower-case "should".

(15) Section 4.3 says "SHOULD send a new ticket." I think we mean to say "= QCD_TOKEN notification" instead of "ticket."

No. = That sentence is about session resumption (RFC 5723), where they do use "ti= ckets". The second sentence talks about tokens:

   For session resumption, as specified in [RFC5723], the situ= ation is
   similar.  The responder, which is nece= ssarily the peer that has
   crashed, SHOULD send a new= ticket within the protected payload of the
   IKE_SESS= ION_RESUME exchange.  If the Initiator is also a token maker,
   it needs to send a QCD_TOKEN in a separate INFORMATIONAL exc= hange.

(16) Section 4.5, is it correct to denote the unprotected message as a "req= uest" in the flow diagrams? I think we were careful in RFC 5996 to denote = standalone messages as informational messages rather than informational req= uests.

OK. I'll change it to "message"

(17) Section 7, change "new IKE SA consume" to "new IKE SA to consume."
=

OK.

(18) Section 7, suggest changing "re-establishment should occur" to either = "would occur" or "will occur."

Agree, but I will = solve it by moving the whole paragraph to the present tense:

   Session resumption, specified in [RFC5723], al= lows the setting up of
   a new IKE SA to consume less = computing resources.  This is
   particularly usef= ul in the case of a remote access gateway that has
   m= any tunnels.  A failure of such a gateway requires all these many
   remote access clients to establish an IKE SA either with= the rebooted
   gateway or with a backup.  This t= unnel re-establishment occurs within
   a short period = of time, creating a burden on the remote access
   gate= way.  Session resumption addresses this problem by having the
   clients store an encrypted derivative of the IKE SA for quic= k re-
   establishment.

(19) Section 8.1, suggest changing "inter-domain VPN gateway" to either add= "an" before it or pluralize "gateway."

Since the= other bullet points are pluralized, I'll go with the former.



Scott Moonen (smoonen@us.ibm.com)=
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/s= moonen

<graycol.gif>Internet-Drafts---0= 1/10/2011 02:48:33 AM---A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work

From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ipsec@ietf.org
Date: 01/10/2011= 02:48 AM
Subject: [IPsec]= I-D Action:draft-ietf-ipsecme-failure-detection-03.txt
Sent by: ipsec-bounces@ietf.org




A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
This draft is a work item of the IP Security Maintenance and Extensions Wor= king Group of the IETF.


Title           : A Quick Crash Detection Metho= d for IKE
Author(s)       : Y. Nir, et al.
Filename        : draft-ietf-ipsecme-failure-detecti= on-03.txt
Pages           : 23
Date            : 2011-01-09

This document describes an extension to the IKEv2 protocol that
allows for faster detection of SA desynchronization using a saved
token.

When an IPsec tunnel between two IKEv2 peers is disconnected due to a
restart of one peer, it can take as much as several minutes for the
other peer to discover that the reboot has occurred, thus delaying
recovery.  In this text we propose an extension to the protocol, that<= br> allows for recovery immediately following the restart.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ip= secme-failure-detection-03.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts= /draft-ietf-ipsecme-failure-detection-03.txt_______________________= ________________________
IPsec mailing list
IPsec@ietf.org
https://ww= w.ietf.org/mailman/listinfo/ipsec

<ATT00001..txt>
= --_000_8F3501F2B20440E399739BA673D8FF86checkpointcom_-- From ynir@checkpoint.com Sun Jan 30 00:11:50 2011 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 642563A68D8 for ; Sun, 30 Jan 2011 00:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.06 X-Spam-Level: X-Spam-Status: No, score=-10.06 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 l-ylh4ZRo21l for ; Sun, 30 Jan 2011 00:11:49 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 184F23A68AF for ; Sun, 30 Jan 2011 00:11:48 -0800 (PST) X-CheckPoint: {4D451E03-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p0U8EwoP008014; Sun, 30 Jan 2011 10:14:58 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Sun, 30 Jan 2011 10:14:58 +0200 From: Yoav Nir To: Scott C Moonen Date: Sun, 30 Jan 2011 10:14:59 +0200 Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt Thread-Index: AcvAVchOYyfuhHW2QAC5Ma1e2ogeFw== Message-ID: <318F190E-8207-473B-8E83-292117652DA5@checkpoint.com> References: <20110110074502.22466.22300.idtracker@localhost> <8F3501F2-B204-40E3-9973-9BA673D8FF86@checkpoint.com> In-Reply-To: <8F3501F2-B204-40E3-9973-9BA673D8FF86@checkpoint.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_318F190E8207473B8E83292117652DA5checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.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, 30 Jan 2011 08:11:50 -0000 --_000_318F190E8207473B8E83292117652DA5checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jan 30, 2011, at 10:00 AM, Yoav Nir wrote: (13) Page 8, the last line is an orphan. Not sure what you mean. It says "In any case, the lack of a QCD_TOKEN notif= ication MUST NOT be taken" and then continues on the next page. OK. Now that Yaron has helped me figure out what an "orphan" is, this is au= tomatic output from the XML2RFC utility. I think the RFC editor takes care = of this before publication. Yoav --_000_318F190E8207473B8E83292117652DA5checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Jan 30, 2= 011, at 10:00 AM, Yoav Nir wrote:

(13) Page 8, the last line is an orphan.

Not sure what you mean. It says "In any case, the lack = of a QCD_TOKEN notification MUST NOT be taken" and then continues on the ne= xt page.

OK. Now that Yaro= n has helped me figure out what an "orphan" is, this is automatic output fr= om the XML2RFC utility. I think the RFC editor takes care of this before pu= blication.

Yoav

= --_000_318F190E8207473B8E83292117652DA5checkpointcom_--