From ynir@checkpoint.com Tue Feb 1 07:02: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 A9FB93A6D23 for ; Tue, 1 Feb 2011 07:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.529, 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 I+Ja2QccCoga for ; Tue, 1 Feb 2011 07:02:13 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 52A0F3A6D20 for ; Tue, 1 Feb 2011 07:02:13 -0800 (PST) X-CheckPoint: {4D482139-20000-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 p11F5TAp029020 for ; Tue, 1 Feb 2011 17:05:29 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Tue, 1 Feb 2011 17:05:28 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Tue, 1 Feb 2011 17:05:26 +0200 Thread-Topic: Failure Detection - issue #202 Thread-Index: AcvCIXX/4gljMhhGSqChoCkKwCrPig== Message-ID: <042D720F-888A-44CB-8414-E145E173EC08@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: [IPsec] Failure Detection - issue #202 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, 01 Feb 2011 15:02:14 -0000 Hi all. Following last week's conf call, Scott Moonen has proposed text to resolve = issue #202. The idea is to remove section 9.4 entirely, and change section = 9.2 as follows: OLD: 9.2. QCD Token Transmission A token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA. This implies that a conforming QCD token maker MUST be able to tell whether a particular pair of IKE SPIs represent a valid IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a QCD token for an IKE SA which is valid on another gateway. This document does not specify how a load sharing configuration of IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members. NEW: 9.2. QCD Token Transmission A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a valid QCD token for an IKE SA which is valid on another gateway. This is true whether the attempt to trick the gateway uses the token taker's IP address or a different IP address. Because it includes the token taker's IP address in the token generation, the method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address. Note that the use of this method causes the tokens to be invalidated whenever the token taker's address changes. It is important to note that this method does not prevent revealing the QCD token to a man-in-the-middle attacker who is spoofing the token taker's IP address, if that attacker is able to direct messages to a cluster member other than the member responsible for the IKE SA. This document does not specify how a load-sharing configuration of IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members. Please discuss this issue this week, as I intend to publish version -04 on = Friday if there are no objections to this change. Yoav From ynir@checkpoint.com Tue Feb 1 13:26:33 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 3FECC3A6C5A for ; Tue, 1 Feb 2011 13:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.078 X-Spam-Level: X-Spam-Status: No, score=-10.078 tagged_above=-999 required=5 tests=[AWL=0.520, 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 clHPRbuqB8LL for ; Tue, 1 Feb 2011 13:26:31 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 99DF13A6C4D for ; Tue, 1 Feb 2011 13:26:30 -0800 (PST) X-CheckPoint: {4D487B4B-20000-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 p11LTlHN020202 for ; Tue, 1 Feb 2011 23:29:47 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Tue, 1 Feb 2011 23:29:47 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Tue, 1 Feb 2011 23:29:45 +0200 Thread-Topic: [IPsec] Failure Detection - issue #202 Thread-Index: AcvCVyY1aRaYJuZNQvmxdvONxlYozA== Message-ID: References: <8587F099-953F-4FCF-A071-8B45AEB3BE1B@cisco.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_EBA37C15DD3E4C3BAF5F58083B453E55checkpointcom_" MIME-Version: 1.0 Subject: [IPsec] Fwd: Failure Detection - issue #202 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, 01 Feb 2011 21:26:33 -0000 --_000_EBA37C15DD3E4C3BAF5F58083B453E55checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding the IPsec list. Begin forwarded message: From: Frederic Detienne > Date: February 1, 2011 9:37:33 PM GMT+02:00 To: Paul Hoffman > Cc: Yoav Nir >, Pratima Set= hi >, Yaron Sheffer > Subject: Re: [IPsec] Failure Detection - issue #202 Hi Paul, Yoav, thanks. We are rather puzzled and have been debating how to address this. The proposal should either properly support Load Balancers or should step d= own and rule out that use case. The statement: -8<--- IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster -8<--- Hides a lot of complexity behind a single sentence. This sentence actually = makes Failure Detection impractical. Simplicity of implementation (as compa= red to SA state synchronization) were key drivers for us in this proposal. The statement should be more precise about the general scenario and be move= d under Security Considerations. -8<--- If an attacker can somehow access a QCD token while the SA's are still acti= ve, this attacker will be able to tear down the sessions at will. In partic= ular, avoiding false positives is critical to the security of the proposal = and a token maker MUST NOT send a QCD token in an unprotected message for a= n existing IKE SA. Practically, IPsec Failure Detection is thus not applicable to deployments = where the QCD token is shared by multiple gateways and the gateways can no= t assess whether the token can be legitimately sent in the clear while anot= her gateway may actually still own the SA's. Load balancer designs typicall= y fall in this category. -8<--- thanks and regards, Frederic On 01 Feb 2011, at 17:51, Paul Hoffman wrote: Pratima and Frederic: Please respond to Yaron and I ASAP, either way, wheth= er or not you agree with the wording. Given that this was your issue and yo= u did not comment during WG LC, we are concerned that we have lost contact = with you. If you do not agree with the wording, you need to say so on the mailing lis= t before Friday. --Paul Hoffman On 2/1/11 7:05 AM, Yoav Nir wrote: Hi all. Following last week's conf call, Scott Moonen has proposed text to resolve = issue #202. The idea is to remove section 9.4 entirely, and change section = 9.2 as follows: OLD: 9.2. QCD Token Transmission A token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA. This implies that a conforming QCD token maker MUST be able to tell whether a particular pair of IKE SPIs represent a valid IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a QCD token for an IKE SA which is valid on another gateway. This document does not specify how a load sharing configuration of IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members. NEW: 9.2. QCD Token Transmission A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a valid QCD token for an IKE SA which is valid on another gateway. This is true whether the attempt to trick the gateway uses the token taker's IP address or a different IP address. Because it includes the token taker's IP address in the token generation, the method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address. Note that the use of this method causes the tokens to be invalidated whenever the token taker's address changes. It is important to note that this method does not prevent revealing the QCD token to a man-in-the-middle attacker who is spoofing the token taker's IP address, if that attacker is able to direct messages to a cluster member other than the member responsible for the IKE SA. This document does not specify how a load-sharing configuration of IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members. Please discuss this issue this week, as I intend to publish version -04 on = Friday if there are no objections to this change. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. --_000_EBA37C15DD3E4C3BAF5F58083B453E55checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding the IPsec list.
=

Begin forwarded message:

From: Frederic Detie= nne <fd@cisco.com>
Date: February 1, 2011 9:37:33 PM GMT+02:00
To: Paul Hoffman <paul.hoffman@vpnc.org>
<= span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0= , 1);">Cc: Yoav Nir <ynir@checkpoin= t.com>, Pratima Sethi <psethi= @cisco.com>, Yaron Sheffer <yaronf.ietf@gmail.com>
= Subject: Re: [IPsec] Failure Detection - issue #202

<= div>Hi Paul, Yoav,

thanks. We are rather puzzled and have been debat= ing how to address this.

The proposal should either properly support= Load Balancers or should step down and rule out that use case.

The = statement:

-8<---
IPsec gateways would work, but in order to support this
&n= bsp; specification, all members MUST be able to tell whether a particu= lar
  IKE SA is active anywhere in the cluster

-8<---

Hides a lot of complexity behind a s= ingle sentence. This sentence actually makes Failure Detection impractical.= Simplicity of implementation (as compared to SA state synchronization) wer= e key drivers for us in this proposal.

The statement should be more = precise about the general scenario and be moved under Security Consideratio= ns.

-8<---
If an attacker can somehow access a QCD token while= the SA's are still active, this attacker will be able to tear down the ses= sions at will. In particular, avoiding false positives is critical to the s= ecurity of the proposal and a token maker MUST NOT send a QCD token in an u= nprotected message for an existing IKE SA.

Practically, IPsec Failur= e Detection is thus not applicable to deployments  where the QCD token= is shared by multiple gateways and the gateways can not assess whether the= token can be legitimately sent in the clear while another gateway may actu= ally still own the SA's. Load balancer designs typically fall in this categ= ory.
-8<---

thanks and regards,

Frederic

On 01 Feb 2011, a= t 17:51, Paul Hoffman wrote:

Pratima and F= rederic: Please respond to Yaron and I ASAP, either way, whether or not you= agree with the wording. Given that this was your issue and you did not com= ment during WG LC, we are concerned that we have lost contact with you.
=

If you do not agree with the wording, you need to say so on the mail= ing list before Friday.

--Paul Hoffman

On 2/1/11 7:05 A= M, Yoav Nir wrote:
Hi all.
=

Following last week's conf call, Scott Moo= nen has proposed text to resolve issue #202. The idea is to remove section = 9.4 entirely, and change section 9.2 as follows:


OLD:

9.2.  QCD Token Transmission
=

  A t= oken maker MUST NOT send a QCD token in an unprotected message for
&= nbsp; an existing IKE SA.  This implies that a conforming QCD tok= en maker
  MUST be able to tell whether a particular pair = of IKE SPIs represent
  a valid IKE SA.

&nbs= p; This requirement is obvious and easy in the case of a single gatewa= y.
  However, some implementations use a load balancer to= divide the load
  between several physical gateways. &nbs= p;It MUST NOT be possible even in
  such a configuration t= o trick one gateway into sending a QCD token
<= blockquote type=3D"cite">
  for an IKE = SA which is valid on another gateway.

<= blockquote type=3D"cite">
  This docume= nt does not specify how a load sharing configuration of
  = IPsec gateways would work, but in order to support this
  = specification, all members MUST be able to tell whether a particular
=   IKE SA is active anywhere in the cluster.  One way to do = it is to
  synchronize a list of active IKE SPIs among all= the cluster members.


NEW:

9.2.  QCD= Token Transmission
=

  A token maker MUST NOT send a= valid QCD token in an unprotected
  message for an existi= ng IKE SA.

  This requirement is obvious and easy i= n the case of a single gateway.
  However, some implementa= tions use a load balancer to divide the load
<= blockquote type=3D"cite">
  between sev= eral physical gateways.  It MUST NOT be possible even in
 =  such a configuration to trick one gateway into sending a valid QCD
  token for an IKE SA which is valid on another gateway. &nb= sp;This is true
  whether the attempt to trick the gateway= uses the token taker's IP
  address or a different IP add= ress.

  Because it includes the token taker's IP ad= dress in the token
<= blockquote type=3D"cite">   generation, the method in Section 5.2= prevents revealing the QCD
  token for an existing pair= of IKE SPIs to an attacker who is using a
  different IP = address.  Note that the use of this method causes the
=
 &nb= sp;tokens to be invalidated whenever the token taker's address changes.
=
  It is important to note that this method does not prevent r= evealing
  the QCD token to a man-in-the-middle attacker w= ho is spoofing the
<= blockquote type=3D"cite">   token taker's IP address, if that att= acker is able to direct messages
  to a cluster member oth= er than the member responsible for the IKE SA.
  This docu= ment does not specify how a load-sharing configuration of
<= /blockquote>
 &nbs= p;IPsec gateways would work, but in order to support this
<= /blockquote>
 &nbs= p;specification, all members MUST be able to tell whether a particular
<= /blockquote>
  IKE SA is active anywhere in the cluster.  One way to d= o it is to
  synchronize a list of active IKE SPIs among a= ll the cluster members.


Please discuss this issue this = week, as I intend to publish version -04 on Friday if there are no objectio= ns to this change.
<= blockquote type=3D"cite">
Yoav

_________________________= ______________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec




Scanned by Check Point To= tal Security Gateway.

= --_000_EBA37C15DD3E4C3BAF5F58083B453E55checkpointcom_-- From wierbows@us.ibm.com Wed Feb 2 06:37: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 CDBF53A6D2A; Wed, 2 Feb 2011 06:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVtuHOLMsUuM; Wed, 2 Feb 2011 06:37:03 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 634A03A6D28; Wed, 2 Feb 2011 06:37:03 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p12EL67L025447; Wed, 2 Feb 2011 09:22:33 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id D1F42728049; Wed, 2 Feb 2011 09:40:10 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p12Ee8mB406586; Wed, 2 Feb 2011 09:40:10 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p12Ee8iP022610; Wed, 2 Feb 2011 09:40:08 -0500 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p12Ee8mI022607; Wed, 2 Feb 2011 09:40:08 -0500 In-Reply-To: References: <8587F099-953F-4FCF-A071-8B45AEB3BE1B@cisco.com> X-KeepSent: 8DA83567:02285246-8525782B:00505BA7; type=4; name=$KeepSent To: Yoav Nir X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: David Wierbowski Date: Wed, 2 Feb 2011 09:40:04 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.5.2FP1|November 29, 2010) at 02/02/2011 09:40:08 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Fwd: Failure Detection - issue #202 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, 02 Feb 2011 14:37:04 -0000 I'm not sure what Frederic means by this statement should "be moved under Security Considerations." Section 9.2 is already in the Security Considerations section. As far as his proposed text, I feel that Scott's text does a better job describing the concern. Frederic's own text does not help with his concern of hiding the complexity in the statement that "all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster." He just reworded the statement to be "Practically, IPsec Failure Detection is thus not applicable to deployments where the QCD token is shared by multiple gateways and the gateways can not assess whether the token can be legitimately sent in the clear while another gateway may actually still own the SA's." Both statements mean the same thing and impose the same requirement. If consensus is that others prefer Frederic's statement over the one that Scott provided us, then I believe the "Practically" should be deleted from the sentence that I mentioned above and the last sentence should be changed to, "Load balancer designs may fall in this category." I don't think we should presume to know what is typical in load balancers. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 From: Yoav Nir To: "ipsec@ietf.org" Date: 02/01/2011 04:30 PM Subject: [IPsec] Fwd: Failure Detection - issue #202 Sent by: ipsec-bounces@ietf.org Adding the IPsec list. Begin forwarded message: From: Frederic Detienne Date: February 1, 2011 9:37:33 PM GMT+02:00 To: Paul Hoffman Cc: Yoav Nir , Pratima Sethi , Yaron Sheffer Subject: Re: [IPsec] Failure Detection - issue #202 Hi Paul, Yoav, thanks. We are rather puzzled and have been debating how to address this. The proposal should either properly support Load Balancers or should step down and rule out that use case. The statement: -8<--- IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster -8<--- Hides a lot of complexity behind a single sentence. This sentence actually makes Failure Detection impractical. Simplicity of implementation (as compared to SA state synchronization) were key drivers for us in this proposal. The statement should be more precise about the general scenario and be moved under Security Considerations. -8<--- If an attacker can somehow access a QCD token while the SA's are still active, this attacker will be able to tear down the sessions at will. In particular, avoiding false positives is critical to the security of the proposal and a token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA. Practically, IPsec Failure Detection is thus not applicable to deployments where the QCD token is shared by multiple gateways and the gateways can not assess whether the token can be legitimately sent in the clear while another gateway may actually still own the SA's. Load balancer designs typically fall in this category. -8<--- thanks and regards, Frederic On 01 Feb 2011, at 17:51, Paul Hoffman wrote: Pratima and Frederic: Please respond to Yaron and I ASAP, either way, whether or not you agree with the wording. Given that this was your issue and you did not comment during WG LC, we are concerned that we have lost contact with you. If you do not agree with the wording, you need to say so on the mailing list before Friday. --Paul Hoffman On 2/1/11 7:05 AM, Yoav Nir wrote: Hi all. Following last week's conf call, Scott Moonen has proposed text to resolve issue #202. The idea is to remove section 9.4 entirely, and change section 9.2 as follows: OLD: 9.2. QCD Token Transmission A token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA. This implies that a conforming QCD token maker MUST be able to tell whether a particular pair of IKE SPIs represent a valid IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a QCD token for an IKE SA which is valid on another gateway. This document does not specify how a load sharing configuration of IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members. NEW: 9.2. QCD Token Transmission A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a valid QCD token for an IKE SA which is valid on another gateway. This is true whether the attempt to trick the gateway uses the token taker's IP address or a different IP address. Because it includes the token taker's IP address in the token generation, the method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address. Note that the use of this method causes the tokens to be invalidated whenever the token taker's address changes. It is important to note that this method does not prevent revealing the QCD token to a man-in-the-middle attacker who is spoofing the token taker's IP address, if that attacker is able to direct messages to a cluster member other than the member responsible for the IKE SA. This document does not specify how a load-sharing configuration of IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members. Please discuss this issue this week, as I intend to publish version -04 on Friday if there are no objections to this change. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Fri Feb 4 07:36: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 F3BFD3A6BC2 for ; Fri, 4 Feb 2011 07:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.759 X-Spam-Level: X-Spam-Status: No, score=-101.759 tagged_above=-999 required=5 tests=[AWL=0.287, 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 zhI7I9GTfAhq for ; Fri, 4 Feb 2011 07:36:15 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 469463A69C3 for ; Fri, 4 Feb 2011 07:36: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 p14FdbIZ017361 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 08:39:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D4C1DB9.8070704@vpnc.org> Date: Fri, 04 Feb 2011 07:39:37 -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: Jai-Jin Lim References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, tim.polk@nist.gov, turners@ieca.com Subject: Re: [IPsec] Questions on the IPsec performance degration or publicly availble results 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, 04 Feb 2011 15:36:16 -0000 On 2/4/11 1:52 AM, Jai-Jin Lim wrote: > Dear whom it may concern, > I am wondering if there is any study regarding the performance > degradation when IPsec is applied to mobile telecommunication networks. > Or at least, is there any link to the general description regarding the > performance degradation in terms of the CPU utilization, throughtput > when IPsec is used for ARM based core processors? If such information is > not available, could you point me out to any link that helps me out with > task of assessing the performace degradation caused by the IPsec (with > H/W encryption and decryptin engine). I have many questions similar to > the ones above, also one like which operation, encryption or decryption, > causes more performance degradation? I know of no such studies I can recommend. Further, I would greatly question the generality of any such study if I saw it. Performance in different CPUs varies *greatly* depending on the type of instructions and register use; this is even true withing sub-types of ARM processors. You probably want to do your own study for your specific intended target CPU and specific level of CPU optimization. --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Fri Feb 4 08:18:54 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 1282A3A69A6; Fri, 4 Feb 2011 08:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=0.978, 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 UbMDWCxwfyxB; Fri, 4 Feb 2011 08:18:52 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id C042B3A69CC; Fri, 4 Feb 2011 08:18:51 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p14G3SWh016818; Fri, 4 Feb 2011 11:03:49 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 874EB72809B; Fri, 4 Feb 2011 11:22:10 -0500 (EST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p14GM9bZ472688; Fri, 4 Feb 2011 11:22:09 -0500 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 p14GM92U018791; Fri, 4 Feb 2011 09:22:09 -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 p14GM9JN018782; Fri, 4 Feb 2011 09:22:09 -0700 In-Reply-To: References: <8587F099-953F-4FCF-A071-8B45AEB3BE1B@cisco.com> X-KeepSent: 5A4BD89C:4B0A6131-8525782D:005979C0; 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: Fri, 4 Feb 2011 11:21:36 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 02/04/2011 09:22:08 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF2BEDFCAFF508f9e8a93df938690918c0ABBF2BEDFCAFF50" X-Content-Scanned: Fidelis XPS MAILER Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir Subject: Re: [IPsec] Fwd: Failure Detection - issue #202 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, 04 Feb 2011 16:18:54 -0000 --0__=0ABBF2BEDFCAFF508f9e8a93df938690918c0ABBF2BEDFCAFF50 Content-type: multipart/alternative; Boundary="1__=0ABBF2BEDFCAFF508f9e8a93df938690918c0ABBF2BEDFCAFF50" --1__=0ABBF2BEDFCAFF508f9e8a93df938690918c0ABBF2BEDFCAFF50 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I'm ok with Frederic's first paragraph as an introduction to the issue;= I don't have a strong preference for his text there or for mine. His second paragraph is lacking a warning that the approach of section = 5.2 does not solve all problems in all cases (e.g., what I communicate in m= y sentence "It is important to note ..."). But I'm ok with either (1) usi= ng my paragraph as-is, (2) making some change to how my paragraph states "= MUST be able to tell ...," (3) or making some change to Frederick's second paragraph to better convey this. 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: Yoav Nir Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Date: 02/02/2011 09:40 AM Subject: Re: [IPsec] Fwd: Failure Detection - issue #202 Sent by: ipsec-bounces@ietf.org I'm not sure what Frederic means by this statement should "be moved und= er Security Considerations." Section 9.2 is already in the Security Considerations section. As far as his proposed text, I feel that Scott's text does a better job= describing the concern. Frederic's own text does not help with his con= cern of hiding the complexity in the statement that "all members MUST be abl= e to tell whether a particular IKE SA is active anywhere in the cluster." H= e just reworded the statement to be "Practically, IPsec Failure Detection= is thus not applicable to deployments where the QCD token is shared by multiple gateways and the gateways can not assess whether the token can= be legitimately sent in the clear while another gateway may actually still= own the SA's." Both statements mean the same thing and impose the same requirement. If consensus is that others prefer Frederic's statement over the one th= at Scott provided us, then I believe the "Practically" should be deleted f= rom the sentence that I mentioned above and the last sentence should be cha= nged to, "Load balancer designs may fall in this category." I don't think w= e should presume to know what is typical in load balancers. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 From: Yoav Nir To: "ipsec@ietf.org" Date: 02/01/2011 04:30 PM Subject: [IPsec] Fwd: Failure Detection - issue #202 Sent by: ipsec-bounces@ietf.org Adding the IPsec list. Begin forwarded message: From: Frederic Detienne Date: February 1, 2011 9:37:33 PM GMT+02:00 To: Paul Hoffman Cc: Yoav Nir , Pratima Sethi , Yaron Sheffer Subject: Re: [IPsec] Failure Detection - issue #202 Hi Paul, Yoav, thanks. We are rather puzzled and have been debating how to addre= ss this. The proposal should either properly support Load Balancers or sho= uld step down and rule out that use case. The statement: -8<--- IPsec gateways would work, but in order to support th= is specification, all members MUST be able to tell whe= ther a particular IKE SA is active anywhere in the cluster -8<--- Hides a lot of complexity behind a single sentence. This sentence= actually makes Failure Detection impractical. Simplicity of implementation (as compared to SA state synchronization) were key= drivers for us in this proposal. The statement should be more precise about the general scenario a= nd be moved under Security Considerations. -8<--- If an attacker can somehow access a QCD token while the SA's are still active, this attacker will be able to tear down the session= s at will. In particular, avoiding false positives is critical to the security of the proposal and a token maker MUST NOT send a QCD to= ken in an unprotected message for an existing IKE SA. Practically, IPsec Failure Detection is thus not applicable to deployments where the QCD token is shared by multiple gateways a= nd the gateways can not assess whether the token can be legitimately= sent in the clear while another gateway may actually still own th= e SA's. Load balancer designs typically fall in this category. -8<--- thanks and regards, Frederic On 01 Feb 2011, at 17:51, Paul Hoffman wrote: Pratima and Frederic: Please respond to Yaron and I ASAP, either way, whether or not you agree with the wording. Give= n that this was your issue and you did not comment during WG = LC, we are concerned that we have lost contact with you. If you do not agree with the wording, you need to say so on= the mailing list before Friday. --Paul Hoffman On 2/1/11 7:05 AM, Yoav Nir wrote: Hi all. Following last week's conf call, Scott Moonen has proposed text to resolve issue #202. The idea is to remove section 9.4 entirely, and change section 9.2 a= s follows: OLD: 9.2. QCD Token Transmission A token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA. This implies that a conforming= QCD token maker MUST be able to tell whether a particular pair of I= KE SPIs represent a valid IKE SA. This requirement is obvious and easy in the case of= a single gateway. However, some implementations use a load balancer t= o divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into send= ing a QCD token for an IKE SA which is valid on another gateway. This document does not specify how a load sharing configuration of IPsec gateways would work, but in order to support = this specification, all members MUST be able to tell whe= ther a particular IKE SA is active anywhere in the cluster. One way = to do it is to synchronize a list of active IKE SPIs among all the= cluster members. NEW: 9.2. QCD Token Transmission A token maker MUST NOT send a valid QCD token in an= unprotected message for an existing IKE SA. This requirement is obvious and easy in the case of= a single gateway. However, some implementations use a load balancer t= o divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into send= ing a valid QCD token for an IKE SA which is valid on another gatew= ay. This is true whether the attempt to trick the gateway uses the t= oken taker's IP address or a different IP address. Because it includes the token taker's IP address in= the token generation, the method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attack= er who is using a different IP address. Note that the use of this me= thod causes the tokens to be invalidated whenever the token taker's= address changes. It is important to note that this method does not prevent revealing the QCD token to a man-in-the-middle attacker who i= s spoofing the token taker's IP address, if that attacker is able = to direct messages to a cluster member other than the member responsib= le for the IKE SA. This document does not specify how a load-sharing configuration of IPsec gateways would work, but in order to support = this specification, all members MUST be able to tell whe= ther a particular IKE SA is active anywhere in the cluster. One way = to do it is to synchronize a list of active IKE SPIs among all the= cluster members. Please discuss this issue this week, as I intend to publish version -04 on Friday if there are no objecti= ons to this change. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. _______________________________________________ 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__=0ABBF2BEDFCAFF508f9e8a93df938690918c0ABBF2BEDFCAFF50 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I'm ok with Frederic's first paragraph as an introduction to the iss= ue; I don't have a strong preference for his text there or for mine.
His second paragraph is lacking a warning that the approach of section = 5.2 does not solve all problems in all cases (e.g., what I communicate = in my sentence "It is important to note ..."). But I'm ok wit= h either (1) using my paragraph as-is, (2) making some change to how my= paragraph states "MUST be able to tell ...," (3) or making s= ome change to Frederick's second paragraph to better convey this.


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

3D"InactiveDavid Wierbowski---0= 2/02/2011 09:40:42 AM---I'm not sure what Frederic means by this statem= ent should "be moved under Security Considerations."
From: David = Wierbowski/Endicott/IBM@IBMUS
To: Yoav Nir= <ynir@checkpoint.com>
Cc: "ip= sec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org
Date: 02/02/= 2011 09:40 AM
Subject: Re:= [IPsec] Fwd: Failure Detection - issue #202
Sent by: ips= ec-bounces@ietf.org




I'm not sure what Frederic means by this statement should "be = moved under
Security Considerations."  Section 9.2 is already in the Secu= rity
Considerations section.

As far as his proposed text, I feel that Scott's text does a better job=
describing the concern.  Frederic's own text does not help with hi= s concern
of hiding the complexity in the statement that "all members MUST b= e able to
tell whether a particular IKE SA is active anywhere in the cluster.&quo= t;  He
just reworded the statement to be "Practically, IPsec Failure Dete= ction is
thus not applicable to deployments  where the QCD token is shared = by
multiple gateways and the gateways can not assess whether the token can= be
legitimately sent in the clear while another gateway may actually still= own
the SA's."    Both statements mean the same thing and im= pose the same
requirement.

If consensus is that others prefer Frederic's statement over the one th= at
Scott provided us, then I believe the "Practically" should be= deleted from
the sentence that I mentioned above and the last sentence should be cha= nged
to, "Load balancer designs may fall in this category."  = I don't think we
should presume to know what is typical in load balancers.


Dave Wierbowski


z/OS Comm Server Developer

Phone:
   Tie line:   620-4055
   External:  607-429-4055






From: Yoav Nir <ynir@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 02/01/2011 04:30 PM
Subject: [IPsec] Fwd:  Failure Detection - issue #202
Sent by: ipsec-bounces@ietf.org



Adding the IPsec list.

Begin forwarded message:

     From: Frederic Detienne <fd@cisco.com>
     Date: February 1, 2011 9:37:33 PM GMT+02:00
     To: Paul Hoffman <paul.hoffman@vpnc.org>
=      Cc: Yoav Nir <ynir@checkpoint.com>, Pratima = Sethi <psethi@cisco.com>,
     Yaron Sheffer <yaronf.ietf@gmail.com>
     Subject: Re: [IPsec] Failure Detection - issue #20= 2

     Hi Paul, Yoav,

     thanks. We are rather puzzled and have been debati= ng how to address
     this.

     The proposal should either properly support Load B= alancers or should
     step down and rule out that use case.

     The statement:

     -8<---
                 IPsec ga= teways would work, but in order to support this
                   s= pecification, all members MUST be able to tell whether
                 a partic= ular
                   I= KE SA is active anywhere in the cluster

     -8<---

     Hides a lot of complexity behind a single sentence= . This sentence
     actually makes Failure Detection impractical. Simp= licity of
     implementation (as compared to SA state synchroniz= ation) were key
     drivers for us in this proposal.

     The statement should be more precise about the gen= eral scenario and
     be moved under Security Considerations.

     -8<---
     If an attacker can somehow access a QCD token whil= e the SA's are
     still active, this attacker will be able to tear d= own the sessions at
     will. In particular, avoiding false positives is c= ritical to the
     security of the proposal and a token maker MUST NO= T send a QCD token
     in an unprotected message for an existing IKE SA.<= br>
     Practically, IPsec Failure Detection is thus not a= pplicable to
     deployments  where the QCD token is shared by= multiple gateways and
     the gateways can not assess whether the token can = be legitimately
     sent in the clear while another gateway may actual= ly still own the
     SA's. Load balancer designs typically fall in this= category.
     -8<---

     thanks and regards,

     Frederic

     On 01 Feb 2011, at 17:51, Paul Hoffman wrote:

           Pratima and Frederic: Please = respond to Yaron and I ASAP,
           either way, whether or not yo= u agree with the wording. Given
           that this was your issue and = you did not comment during WG LC,
           we are concerned that we have= lost contact with you.

           If you do not agree with the = wording, you need to say so on the
           mailing list before Friday.
           --Paul Hoffman

           On 2/1/11 7:05 AM, Yoav Nir w= rote:
                 Hi all.<= br>
                 Followin= g last week's conf call, Scott Moonen has
                 proposed= text to resolve issue #202. The idea is to
                 remove s= ection 9.4 entirely, and change section 9.2 as
                 follows:=


                 OLD:
=
                 9.2. &nb= sp;QCD Token Transmission

                   A= token maker MUST NOT send a QCD token in an
                 unprotec= ted message for
                   a= n existing IKE SA.  This implies that a conforming QCD
                 token ma= ker
                   M= UST be able to tell whether a particular pair of IKE
                 SPIs rep= resent
                   a= valid IKE SA.

                   T= his requirement is obvious and easy in the case of a
                 single g= ateway.
                   H= owever, some implementations use a load balancer to
                 divide t= he load
                   b= etween several physical gateways.  It MUST NOT be
                 possible= even in
                   s= uch a configuration to trick one gateway into sending
                 a QCD to= ken
                   f= or an IKE SA which is valid on another gateway.

                   T= his document does not specify how a load sharing
                 configur= ation of
                   I= Psec gateways would work, but in order to support this
                   s= pecification, all members MUST be able to tell whether
                 a partic= ular
                   I= KE SA is active anywhere in the cluster.  One way to
                 do it is= to
                   s= ynchronize a list of active IKE SPIs among all the
                 cluster = members.


                 NEW:
=
                 9.2. &nb= sp;QCD Token Transmission

                   A= token maker MUST NOT send a valid QCD token in an
                 unprotec= ted
                   m= essage for an existing IKE SA.

                   T= his requirement is obvious and easy in the case of a
                 single g= ateway.
                   H= owever, some implementations use a load balancer to
                 divide t= he load
                   b= etween several physical gateways.  It MUST NOT be
                 possible= even in
                   s= uch a configuration to trick one gateway into sending
                 a valid = QCD
                   t= oken for an IKE SA which is valid on another gateway.
                 This is = true
                   w= hether the attempt to trick the gateway uses the token
                 taker's = IP
                   a= ddress or a different IP address.

                   B= ecause it includes the token taker's IP address in the
                 token                    g= eneration, the method in Section 5.2 prevents
                 revealin= g the QCD
                   t= oken for an existing pair of IKE SPIs to an attacker
                 who is u= sing a
                   d= ifferent IP address.  Note that the use of this method
                 causes t= he
                   t= okens to be invalidated whenever the token taker's
                 address = changes.
                   I= t is important to note that this method does not
                 prevent = revealing
                   t= he QCD token to a man-in-the-middle attacker who is
                 spoofing= the
                   t= oken taker's IP address, if that attacker is able to
                 direct m= essages
                   t= o a cluster member other than the member responsible
                 for the = IKE SA.
                   T= his document does not specify how a load-sharing
                 configur= ation of
                   I= Psec gateways would work, but in order to support this
                   s= pecification, all members MUST be able to tell whether
                 a partic= ular
                   I= KE SA is active anywhere in the cluster.  One way to
                 do it is= to
                   s= ynchronize a list of active IKE SPIs among all the
                 cluster = members.


                 Please d= iscuss this issue this week, as I intend to
                 publish = version -04 on Friday if there are no objections
                 to this = change.

                 Yoav
=
                 ________= _______________________________________
                 IPsec ma= iling list
                 IPsec@ie= tf.org
                 https://www.ie= tf.org/mailman/listinfo/ipsec





     Scanned by Check Point Total Security Gateway.
= _______________________________________________
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__=0ABBF2BEDFCAFF508f9e8a93df938690918c0ABBF2BEDFCAFF50-- --0__=0ABBF2BEDFCAFF508f9e8a93df938690918c0ABBF2BEDFCAFF50 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF2BEDFCAFF508f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF2BEDFCAFF508f9e8a93df938690918c0ABBF2BEDFCAFF50-- From jjinlim@gmail.com Fri Feb 4 01:49:02 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 CBF663A68B7 for ; Fri, 4 Feb 2011 01:49:02 -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 tX7qpf4hOK5g for ; Fri, 4 Feb 2011 01:49:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E81A33A689B for ; Fri, 4 Feb 2011 01:49:01 -0800 (PST) Received: by vws7 with SMTP id 7so1398178vws.31 for ; Fri, 04 Feb 2011 01:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=Qpv3NiM3nkMn5zOLlxkvitTfdmwaqQ5SajEQ5PEl+UQ=; b=MuQt+oGLXF6twtPu2rS8IXzBPFfkLo1WEbnpIhSGUUfyY9gf+KSSRMqxEw0Jx4xNDy bnSnJOZ8GrkLyivGShhSwcg8u+xq6j2g0nX8li2yxG8BNK93gunet7xvrK77SDXa5hmc K/PRxQ2dJeM3dhyYsYbhCFG3gLa7UARafipL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=LNtrIKG59MwXzG5xanNoHDvkewBEiFaBJ5eHlAzkTSVkUeEBqZa1E4DYicuMz4WB82 1ZOOirS7YPql2z+m+LIC/BJ53raCXFr8OWKN4l96/YIyMbqcSR6tpWfno5FF9i/X4sEU KHa7FZtrjfdS649cz8y7zbTQ9M5nXvgw8g18E= MIME-Version: 1.0 Received: by 10.220.170.78 with SMTP id c14mr2963877vcz.205.1296813145946; Fri, 04 Feb 2011 01:52:25 -0800 (PST) Received: by 10.220.202.201 with HTTP; Fri, 4 Feb 2011 01:52:25 -0800 (PST) Date: Fri, 4 Feb 2011 18:52:25 +0900 Message-ID: From: Jai-Jin Lim To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e6897022e77c95049b71d674 X-Mailman-Approved-At: Fri, 04 Feb 2011 08:19:55 -0800 Cc: tim.polk@nist.gov, turners@ieca.com, paul.hoffman@vpnc.org Subject: [IPsec] Questions on the IPsec performance degration or publicly availble results 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, 04 Feb 2011 09:49:03 -0000 --0016e6897022e77c95049b71d674 Content-Type: text/plain; charset=ISO-8859-1 Dear whom it may concern, I am wondering if there is any study regarding the performance degradation when IPsec is applied to mobile telecommunication networks. Or at least, is there any link to the general description regarding the performance degradation in terms of the CPU utilization, throughtput when IPsec is used for ARM based core processors? If such information is not available, could you point me out to any link that helps me out with task of assessing the performace degradation caused by the IPsec (with H/W encryption and decryptin engine). I have many questions similar to the ones above, also one like which operation, encryption or decryption, causes more performance degradation? Regards, --Jj --0016e6897022e77c95049b71d674 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear whom it may concern,
=A0
I am wondering if there is any study regarding the performance degrada= tion when IPsec is applied to mobile telecommunication networks. Or at leas= t, is there any link to the general description regarding the performance d= egradation in terms of the CPU utilization, throughtput when IPsec is used = for ARM based core processors? If such information is not available, could = you point me out to any link that helps me out with task of assessing the p= erformace degradation caused by the IPsec (with H/W encryption and decrypti= n engine). I have many questions similar to the ones above, also one like w= hich operation, encryption or decryption, causes more performance degradati= on?
=A0
Regards,
--Jj
--0016e6897022e77c95049b71d674-- From paul.hoffman@vpnc.org Sun Feb 6 12:34:30 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 E8C973A6A42 for ; Sun, 6 Feb 2011 12:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.096 X-Spam-Level: X-Spam-Status: No, score=-100.096 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, 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 uHiN-53zwL07 for ; Sun, 6 Feb 2011 12:34:30 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 24E5E3A69B5 for ; Sun, 6 Feb 2011 12:34:30 -0800 (PST) Received: from MacBook-08.local (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p16KYRAo020922 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 6 Feb 2011 13:34:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D4F05D3.2000500@vpnc.org> Date: Sun, 06 Feb 2011 12:34:27 -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: RFC Errata System References: <20110206195155.7E421E0701@rfc-editor.org> In-Reply-To: <20110206195155.7E421E0701@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pe@iki.fi, tim.polk@nist.gov, charliek@microsoft.com, ynir@checkpoint.com, ipsec@ietf.org, turners@ieca.com Subject: Re: [IPsec] [Technical Errata Reported] RFC5996 (2707) 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, 06 Feb 2011 20:34:31 -0000 Verified From wwwrun@rfc-editor.org Sun Feb 6 11:51:53 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 C0F043A697E for ; Sun, 6 Feb 2011 11:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XhiUJDbbpsZG for ; Sun, 6 Feb 2011 11:51:53 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 09B1A3A68FA for ; Sun, 6 Feb 2011 11:51:53 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7E421E0701; Sun, 6 Feb 2011 11:51:55 -0800 (PST) To: charliek@microsoft.com, paul.hoffman@vpnc.org, ynir@checkpoint.com, pe@iki.fi, turners@ieca.com, tim.polk@nist.gov, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com From: RFC Errata System Message-Id: <20110206195155.7E421E0701@rfc-editor.org> Date: Sun, 6 Feb 2011 11:51:55 -0800 (PST) X-Mailman-Approved-At: Sun, 06 Feb 2011 14:24:33 -0800 Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] [Technical Errata Reported] RFC5996 (2707) 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, 06 Feb 2011 19:51:53 -0000 The following errata report has been submitted for RFC5996, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5996&eid=2707 -------------------------------------- Type: Technical Reported by: Yaron Sheffer Section: 3.6 Original Text ------------- [...] and also MUST be capable of being configured to send and accept the Hash and URL format (with HTTP URLs) Corrected Text -------------- [...] and also MUST be capable of being configured to send and accept the two Hash and URL formats (with HTTP URLs) Notes ----- This change from the original RFC 4306 text was made late in the process, responding to the Gen-Art reviewer comment. Factually, the document (earlier in the same section) defines two Hash and URL formats, making this sentence a clear inconsistency. The erratum is flagged as Technical because the text is normative. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5996 (draft-ietf-ipsecme-ikev2bis-11) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : September 2010 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From paul.hoffman@vpnc.org Mon Feb 7 12:20: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 815783A6EAF for ; Mon, 7 Feb 2011 12:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.879 X-Spam-Level: X-Spam-Status: No, score=-99.879 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, 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 uisbL30Aqd1y for ; Mon, 7 Feb 2011 12:20:18 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D5E083A6E94 for ; Mon, 7 Feb 2011 12:20: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 p17KKMiH074543 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 7 Feb 2011 13:20:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D505406.3080508@vpnc.org> Date: Mon, 07 Feb 2011 12:20:22 -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: <8587F099-953F-4FCF-A071-8B45AEB3BE1B@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Fwd: Failure Detection - issue #202 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, 07 Feb 2011 20:20:19 -0000 Any other comments on this issue and the proposals for wording? --Paul Hoffman, Director --VPN Consortium From welterk@us.ibm.com Tue Feb 8 08:23: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 627343A672E for ; Tue, 8 Feb 2011 08:23:58 -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 AttdTHqqgHWd for ; Tue, 8 Feb 2011 08:23:57 -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 D883B3A67E3 for ; Tue, 8 Feb 2011 08:23:56 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p18GCWBB006069 for ; Tue, 8 Feb 2011 09:12:33 -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 p18GNpaV253478 for ; Tue, 8 Feb 2011 09:23: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 p18GNo2d000401 for ; Tue, 8 Feb 2011 09:23: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 p18GNot6000394; Tue, 8 Feb 2011 09:23:50 -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: 8145B74F:E8EC1EE7-88257831:0059A967; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Tue, 8 Feb 2011 08:23:49 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 02/08/2011 09:23:50, Serialize complete at 02/08/2011 09:23:50 Content-Type: multipart/alternative; boundary="=_alternative 005A134188257831_=" 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: Tue, 08 Feb 2011 16:23:58 -0000 This is a multipart message in MIME format. --=_alternative 005A134188257831_= Content-Type: text/plain; charset="US-ASCII" I contacted Hugo Krawczyk, the SIGMA author, and he agreed to evaluate the security considerations of the draft. He's busy at the moment though so we won't be able to pick-up the thread for a couple weeks. > > 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>. --=_alternative 005A134188257831_= Content-Type: text/html; charset="US-ASCII"
I contacted Hugo Krawczyk, the SIGMA author, and he agreed to evaluate the security considerations of the draft.  He's busy at the moment though so we won't be able to pick-up the thread for a couple weeks.

> > 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>.
 --=_alternative 005A134188257831_=-- From fd@cisco.com Tue Feb 8 09:47: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 1CF473A67AD; Tue, 8 Feb 2011 09:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvWjBDxigKsi; Tue, 8 Feb 2011 09:47:49 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EE5D43A679F; Tue, 8 Feb 2011 09:47:48 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p18HSZ0R017249; Tue, 8 Feb 2011 18:28:35 +0100 (CET) Received: from dhcp-64-103-13-68.cisco.com (dhcp-64-103-13-68.cisco.com [64.103.13.68]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p18HSTG1012491; Tue, 8 Feb 2011 18:28:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Frederic Detienne In-Reply-To: Date: Tue, 8 Feb 2011 18:28:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6B89801F-AC31-453D-ABA3-E38B3871672D@cisco.com> References: <8587F099-953F-4FCF-A071-8B45AEB3BE1B@cisco.com> To: Scott C Moonen X-Mailer: Apple Mail (2.1082) Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, David Wierbowski , Yoav Nir Subject: Re: [IPsec] Fwd: Failure Detection - issue #202 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, 08 Feb 2011 17:47:51 -0000 Hi Scott, I just felt that the _why_ the tokens had to be protected was not so = precisely covered (clarity). My re-write was only intended for the = beginning of the section. I agree that knowing the SA state is the only solution that we can think = of but it is barely a solution in practice. This is why I stated it in a = negative way ("MUST NOT send" rather than "MUST verify"). But I agree = the statement is roughly the same. I also agree that 5.2 does not solve all problems and I do not mean to = remove that part. It is good to keep it. One more comment on section 9.3 (QCD Token Enumeration): -8<--- The methods in Section 5.1 and Section 5.2 allow for a periodic change of the QCD_SECRET. Any such change invalidates the entire dictionary. -8<--- Don't we mean that section 4.4 allows the replacement of the tokens = should the QCD_SECRET change ? thanks and regards, fred On 04 Feb 2011, at 17:21, Scott C Moonen wrote: > I'm ok with Frederic's first paragraph as an introduction to the = issue; I don't have a strong preference for his text there or for mine. >=20 > His second paragraph is lacking a warning that the approach of section = 5.2 does not solve all problems in all cases (e.g., what I communicate = in my sentence "It is important to note ..."). But I'm ok with either = (1) using my paragraph as-is, (2) making some change to how my paragraph = states "MUST be able to tell ...," (3) or making some change to = Frederick's second paragraph to better convey this. >=20 >=20 > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen >=20 > David Wierbowski---02/02/2011 09:40:42 AM---I'm not sure = what Frederic means by this statement should "be moved under Security = Considerations." >=20 > From: David Wierbowski/Endicott/IBM@IBMUS > To: Yoav Nir > Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org > Date: 02/02/2011 09:40 AM > Subject: Re: [IPsec] Fwd: Failure Detection - issue #202 > Sent by: ipsec-bounces@ietf.org >=20 >=20 >=20 > I'm not sure what Frederic means by this statement should "be moved = under > Security Considerations." Section 9.2 is already in the Security > Considerations section. >=20 > As far as his proposed text, I feel that Scott's text does a better = job > describing the concern. Frederic's own text does not help with his = concern > of hiding the complexity in the statement that "all members MUST be = able to > tell whether a particular IKE SA is active anywhere in the cluster." = He > just reworded the statement to be "Practically, IPsec Failure = Detection is > thus not applicable to deployments where the QCD token is shared by > multiple gateways and the gateways can not assess whether the token = can be > legitimately sent in the clear while another gateway may actually = still own > the SA's." Both statements mean the same thing and impose the same > requirement. >=20 > If consensus is that others prefer Frederic's statement over the one = that > Scott provided us, then I believe the "Practically" should be deleted = from > the sentence that I mentioned above and the last sentence should be = changed > to, "Load balancer designs may fall in this category." I don't think = we > should presume to know what is typical in load balancers. >=20 >=20 > Dave Wierbowski >=20 >=20 > z/OS Comm Server Developer >=20 > Phone: > Tie line: 620-4055 > External: 607-429-4055 >=20 >=20 >=20 >=20 >=20 >=20 > From: Yoav Nir > To: "ipsec@ietf.org" > Date: 02/01/2011 04:30 PM > Subject: [IPsec] Fwd: Failure Detection - issue #202 > Sent by: ipsec-bounces@ietf.org >=20 >=20 >=20 > Adding the IPsec list. >=20 > Begin forwarded message: >=20 > From: Frederic Detienne > Date: February 1, 2011 9:37:33 PM GMT+02:00 > To: Paul Hoffman > Cc: Yoav Nir , Pratima Sethi = , > Yaron Sheffer > Subject: Re: [IPsec] Failure Detection - issue #202 >=20 > Hi Paul, Yoav, >=20 > thanks. We are rather puzzled and have been debating how to = address > this. >=20 > The proposal should either properly support Load Balancers or = should > step down and rule out that use case. >=20 > The statement: >=20 > -8<--- > IPsec gateways would work, but in order to support = this > specification, all members MUST be able to tell = whether > a particular > IKE SA is active anywhere in the cluster >=20 > -8<--- >=20 > Hides a lot of complexity behind a single sentence. This sentence > actually makes Failure Detection impractical. Simplicity of > implementation (as compared to SA state synchronization) were key > drivers for us in this proposal. >=20 > The statement should be more precise about the general scenario = and > be moved under Security Considerations. >=20 > -8<--- > If an attacker can somehow access a QCD token while the SA's are > still active, this attacker will be able to tear down the = sessions at > will. In particular, avoiding false positives is critical to the > security of the proposal and a token maker MUST NOT send a QCD = token > in an unprotected message for an existing IKE SA. >=20 > Practically, IPsec Failure Detection is thus not applicable to > deployments where the QCD token is shared by multiple gateways = and > the gateways can not assess whether the token can be legitimately > sent in the clear while another gateway may actually still own = the > SA's. Load balancer designs typically fall in this category. > -8<--- >=20 > thanks and regards, >=20 > Frederic >=20 > On 01 Feb 2011, at 17:51, Paul Hoffman wrote: >=20 > Pratima and Frederic: Please respond to Yaron and I ASAP, > either way, whether or not you agree with the wording. = Given > that this was your issue and you did not comment during WG = LC, > we are concerned that we have lost contact with you. >=20 > If you do not agree with the wording, you need to say so on = the > mailing list before Friday. >=20 > --Paul Hoffman >=20 > On 2/1/11 7:05 AM, Yoav Nir wrote: > Hi all. >=20 > Following last week's conf call, Scott Moonen has > proposed text to resolve issue #202. The idea is to > remove section 9.4 entirely, and change section 9.2 = as > follows: >=20 >=20 > OLD: >=20 > 9.2. QCD Token Transmission >=20 > A token maker MUST NOT send a QCD token in an > unprotected message for > an existing IKE SA. This implies that a conforming = QCD > token maker > MUST be able to tell whether a particular pair of = IKE > SPIs represent > a valid IKE SA. >=20 > This requirement is obvious and easy in the case of = a > single gateway. > However, some implementations use a load balancer = to > divide the load > between several physical gateways. It MUST NOT be > possible even in > such a configuration to trick one gateway into = sending > a QCD token > for an IKE SA which is valid on another gateway. >=20 > This document does not specify how a load sharing > configuration of > IPsec gateways would work, but in order to support = this > specification, all members MUST be able to tell = whether > a particular > IKE SA is active anywhere in the cluster. One way = to > do it is to > synchronize a list of active IKE SPIs among all the > cluster members. >=20 >=20 > NEW: >=20 > 9.2. QCD Token Transmission >=20 > A token maker MUST NOT send a valid QCD token in an > unprotected > message for an existing IKE SA. >=20 > This requirement is obvious and easy in the case of = a > single gateway. > However, some implementations use a load balancer = to > divide the load > between several physical gateways. It MUST NOT be > possible even in > such a configuration to trick one gateway into = sending > a valid QCD > token for an IKE SA which is valid on another = gateway. > This is true > whether the attempt to trick the gateway uses the = token > taker's IP > address or a different IP address. >=20 > Because it includes the token taker's IP address in = the > token > generation, the method in Section 5.2 prevents > revealing the QCD > token for an existing pair of IKE SPIs to an = attacker > who is using a > different IP address. Note that the use of this = method > causes the > tokens to be invalidated whenever the token taker's > address changes. > It is important to note that this method does not > prevent revealing > the QCD token to a man-in-the-middle attacker who = is > spoofing the > token taker's IP address, if that attacker is able = to > direct messages > to a cluster member other than the member = responsible > for the IKE SA. > This document does not specify how a load-sharing > configuration of > IPsec gateways would work, but in order to support = this > specification, all members MUST be able to tell = whether > a particular > IKE SA is active anywhere in the cluster. One way = to > do it is to > synchronize a list of active IKE SPIs among all the > cluster members. >=20 >=20 > Please discuss this issue this week, as I intend to > publish version -04 on Friday if there are no = objections > to this change. >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From wwwrun@rfc-editor.org Tue Feb 8 11:41: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 3E0C93A67F9; Tue, 8 Feb 2011 11:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.95 X-Spam-Level: X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 SoIv4PMB-lxm; Tue, 8 Feb 2011 11:41:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 19E793A67F6; Tue, 8 Feb 2011 11:41:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C1FCFE073F; Tue, 8 Feb 2011 11:41:43 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110208194143.C1FCFE073F@rfc-editor.org> Date: Tue, 8 Feb 2011 11:41:43 -0800 (PST) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 6071 on IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap 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, 08 Feb 2011 19:41:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6071 Title: IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author: S. Frankel, S. Krishnan Status: Informational Stream: IETF Date: February 2011 Mailbox: sheila.frankel@nist.gov, suresh.krishnan@ericsson.com Pages: 63 Characters: 148655 Obsoletes: RFC2411 I-D Tag: draft-ietf-ipsecme-roadmap-10.txt URL: http://www.rfc-editor.org/rfc/rfc6071.txt Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap." The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From turners@ieca.com Tue Feb 8 11:43: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 3548E3A6860 for ; Tue, 8 Feb 2011 11:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 nuHlVaG61zEL for ; Tue, 8 Feb 2011 11:43:45 -0800 (PST) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by core3.amsl.com (Postfix) with SMTP id D72903A6866 for ; Tue, 8 Feb 2011 11:43:41 -0800 (PST) Received: from [98.139.91.62] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 08 Feb 2011 19:43:48 -0000 Received: from [98.139.91.25] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 08 Feb 2011 19:43:48 -0000 Received: from [127.0.0.1] by omp1025.mail.sp2.yahoo.com with NNFMP; 08 Feb 2011 19:43:48 -0000 X-Yahoo-Newman-Id: 692996.39127.bm@omp1025.mail.sp2.yahoo.com Received: (qmail 86121 invoked from network); 8 Feb 2011 19:43:48 -0000 Received: from thunderfish.local (turners@71.191.10.60 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 08 Feb 2011 11:43:47 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: JFPlcKYVM1lvNrtxVm6DDOOm7I5KQmsfSCNSXrRm7o7R7ig ewZ35462K7DP3AOl.OJXClH6fyIH4er4iYTPaoYr14FSpKaFO7CEO4_SZGvl g4dDvw2eudqGIj5AIksXywyvci_9tpIp8Oc5QaF.KEgeMRFAsXnRrvvxEGej elO9UR9KW6OKd4nSrnp1jPOtQpbrtbbXTEMiffgQnXX2xJJV1jtxtcK9g3WP NNlpwbgMSYRO07bFSsd2IOWlqwK9HUkf_hsSKvL6zMwIv5z4QKzmYT1Fo0wZ 747zkAbVDHFVOzZ4z2uiwdH4Wu.6j26SDyh212t8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D519CF3.6080501@ieca.com> Date: Tue, 08 Feb 2011 14:43:47 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipsec@ietf.org References: <20110208194143.C1FCFE073F@rfc-editor.org> In-Reply-To: <20110208194143.C1FCFE073F@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] RFC 6071 on IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap 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, 08 Feb 2011 19:43:46 -0000 Congrats to all involved for getting this done. spt On 2/8/11 2:41 PM, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6071 > > Title: IP Security (IPsec) and Internet > Key Exchange (IKE) Document Roadmap > Author: S. Frankel, S. Krishnan > Status: Informational > Stream: IETF > Date: February 2011 > Mailbox: sheila.frankel@nist.gov, > suresh.krishnan@ericsson.com > Pages: 63 > Characters: 148655 > Obsoletes: RFC2411 > > I-D Tag: draft-ietf-ipsecme-roadmap-10.txt > > URL: http://www.rfc-editor.org/rfc/rfc6071.txt > > Over the past few years, the number of RFCs that define and use IPsec > and Internet Key Exchange (IKE) has greatly proliferated. This is > complicated by the fact that these RFCs originate from numerous IETF > working groups: the original IPsec WG, its various spin-offs, and > other WGs that use IPsec and/or IKE to protect their protocols' > traffic. > > This document is a snapshot of IPsec- and IKE-related RFCs. It > includes a brief description of each RFC, along with background > information explaining the motivation and context of IPsec's > outgrowths and extensions. It obsoletes RFC 2411, the previous > "IP Security Document Roadmap." > > The obsoleted IPsec roadmap (RFC 2411) briefly described the > interrelationship of the various classes of base IPsec documents. > The major focus of RFC 2411 was to specify the recommended contents > of documents specifying additional encryption and authentication > algorithms. This document is not an Internet Standards Track > specification; it is published for informational purposes. > > This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Internet-Drafts@ietf.org Tue Feb 8 11:45:02 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 EC90B3A6860; Tue, 8 Feb 2011 11:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6ObIeNFSuajc; Tue, 8 Feb 2011 11:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AABA3A685B; Tue, 8 Feb 2011 11: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.12 Message-ID: <20110208194502.32308.76943.idtracker@localhost> Date: Tue, 08 Feb 2011 11:45:02 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-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: Tue, 08 Feb 2011 19:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Protocol Support for High Availability of IKEv2/IPsec Author(s) : R. Jenwar, et al. Filename : draft-ietf-ipsecme-ipsecha-protocol-03.txt Pages : 22 Date : 2011-02-08 The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However there are many issues in IPsec HA clustering, and in particular in IKEv2 clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document attempts to resolve these issues with the least possible change to the protocol. This document proposes an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot-standby cluster, and provides implementation advice for other issues. The main issues to be solved are the synchronization of IKEv2 Message ID counters, and of IPsec Replay Counters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-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-ipsecha-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08114345.I-D@ietf.org> --NextPart-- From yaronf.ietf@gmail.com Tue Feb 8 12:15:13 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 741D43A681D for ; Tue, 8 Feb 2011 12:15:13 -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=[BAYES_00=-2.599, 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 r9KVLzxzjG4f for ; Tue, 8 Feb 2011 12:15:11 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 924E73A672E for ; Tue, 8 Feb 2011 12:15:11 -0800 (PST) Received: by wwa36 with SMTP id 36so6657003wwa.13 for ; Tue, 08 Feb 2011 12:15:18 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SMEyxy6wyVsnfguZ9YqxwwvZPHG8t5dbm/GW9RyZV/k=; b=lACQKuvuME+fx4CHOKbRkzWjhGT7wuQZ0yOAaN+T67yw06rQ46G12pe8doP2LTFp4V iRlcgeS+fUNYpUPzbAtB8fAesYwQNcaaLDsjBf7ioYIgfL9RMQRPXeK8ekmJSqp88CMZ YH5KtbFeOnl4F3whrsRSWRX1oaythsRZUEF3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=sTP0FsLd6zu4XqoMFPThLzRhhCXziDe1rx0RNpjTeqBjvd+7pyGqi08zCUdhQvrHk7 gPq/lkMMOOe5LFPYR4abADN9sGQwEHLY2x1jbN1Pbw0qaKUqB5Xjcq9V0qwOLANLsRW1 8Oc7kzrrk2nYYG3AvUoxw9+0/mGG2Sc11yArE= Received: by 10.227.145.143 with SMTP id d15mr18150486wbv.91.1297196118237; Tue, 08 Feb 2011 12:15:18 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id u9sm4756549wbg.0.2011.02.08.12.15.16 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 12:15:17 -0800 (PST) Message-ID: <4D51A453.1010802@gmail.com> Date: Tue, 08 Feb 2011 22:15:15 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipsec@ietf.org References: <20110208194502.32308.76943.idtracker@localhost> In-Reply-To: <20110208194502.32308.76943.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-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: Tue, 08 Feb 2011 20:15:13 -0000 Hi, this version attempts to address all the open issues that were raised in the last few months. In particular, it clarifies the behavior of the IKE Message ID during failover while reducing some of the complexity. Another significant change is the semantics of the IPsec replay counter sync message. Pleas review the document. We would like to close the issues in the next week or so, and move to WGLC. The currently open issues are here: http://tools.ietf.org/wg/ipsecme/trac/query?status=new&status=assigned&status=reopened&component=ipsecha-protocol Thanks, Yaron On 02/08/2011 09:45 PM, Internet-Drafts@ietf.org wrote: > 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 : Protocol Support for High Availability of IKEv2/IPsec > Author(s) : R. Jenwar, et al. > Filename : draft-ietf-ipsecme-ipsecha-protocol-03.txt > Pages : 22 > Date : 2011-02-08 > > The IPsec protocol suite is widely used for business-critical network > traffic. In order to make IPsec deployments highly available, more > scalable and failure-resistant, they are often implemented as IPsec > High Availability (HA) clusters. However there are many issues in > IPsec HA clustering, and in particular in IKEv2 clustering. An > earlier document, "IPsec Cluster Problem Statement", enumerates the > issues encountered in the IKEv2/IPsec HA cluster environment. This > document attempts to resolve these issues with the least possible > change to the protocol. > > This document proposes an extension to the IKEv2 protocol to solve > the main issues of "IPsec Cluster Problem Statement" in the commonly > deployed hot-standby cluster, and provides implementation advice for > other issues. The main issues to be solved are the synchronization > of IKEv2 Message ID counters, and of IPsec Replay Counters. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-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. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Thu Feb 10 00:22:35 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 3BBE83A69DD for ; Thu, 10 Feb 2011 00:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-bLmFvFpw8o for ; Thu, 10 Feb 2011 00:22:34 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 530303A6923 for ; Thu, 10 Feb 2011 00:22:33 -0800 (PST) X-CheckPoint: {4D53A054-20000-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 p1A8Mg6M015801; Thu, 10 Feb 2011 10:22:42 +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; Thu, 10 Feb 2011 10:22:42 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 10 Feb 2011 10:22:42 +0200 From: Yoav Nir To: Yaron Sheffer Date: Thu, 10 Feb 2011 10:22:44 +0200 Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-03.txt Thread-Index: AcvI+6+wSnoW2z4aQdub8jLZXeeKVQ== Message-ID: <372CB5F4-0567-4622-B850-0869B89940B1@checkpoint.com> References: <20110208194502.32308.76943.idtracker@localhost> <4D51A453.1010802@gmail.com> In-Reply-To: <4D51A453.1010802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-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: Thu, 10 Feb 2011 08:22:35 -0000 Hi Yaron I think this addresses the issues well. However, there is one more thing. Section 3 is currently in skeleton form and needs to be expanded a lot. For example, RFC 6027 says the following: o It requires multiple parallel SAs, for which the peer has no use. Section 2.8 of [RFC5996] specifically allows this, but some implementation might have a policy against long-term maintenance of redundant SAs. And draft-ietf-ipsecme-ipsecha-protocol says: o 3.7 is an implementation problem that needs to be solved while building IPsec clusters. However, the peers should be required to accept multiple parallel SAs for 3.7.1. It's true that RFC 5996 seems to require this support already, but what it = actually says is this: Note that IKEv2 deliberately allows parallel SAs with the same Traffic Selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints and the Traffic Selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate Traffic Selectors SHOULD NOT be used. So RFC 5996 justifies parallel SAs by QoS, not by clusters. I think Section= 3 should be much clearer and contain MUST requirements for a peer to suppo= rt a reasonable amount of parallel SAs.=20 This is but one example. Section 3 contains a brief sentence about each pro= blem defined in RFC 6027 without a single RFC 2119 term in there. I think t= hose sentences need to be expanded to paragraphs or sub-section with requir= ement levels. And yes, I will propose text. Soon. Promise. Yoav On Feb 8, 2011, at 10:15 PM, Yaron Sheffer wrote: > Hi, >=20 > this version attempts to address all the open issues that were raised in= =20 > the last few months. In particular, it clarifies the behavior of the IKE= =20 > Message ID during failover while reducing some of the complexity.=20 > Another significant change is the semantics of the IPsec replay counter=20 > sync message. >=20 > Pleas review the document. We would like to close the issues in the next= =20 > week or so, and move to WGLC. The currently open issues are here:=20 > http://tools.ietf.org/wg/ipsecme/trac/query?status=3Dnew&status=3Dassigne= d&status=3Dreopened&component=3Dipsecha-protocol >=20 > Thanks, > Yaron >=20 > On 02/08/2011 09:45 PM, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the IP Security Maintenance and Extensions = Working Group of the IETF. >>=20 >>=20 >> Title : Protocol Support for High Availability of IKEv2/IPsec >> Author(s) : R. Jenwar, et al. >> Filename : draft-ietf-ipsecme-ipsecha-protocol-03.txt >> Pages : 22 >> Date : 2011-02-08 >>=20 >> The IPsec protocol suite is widely used for business-critical network >> traffic. In order to make IPsec deployments highly available, more >> scalable and failure-resistant, they are often implemented as IPsec >> High Availability (HA) clusters. However there are many issues in >> IPsec HA clustering, and in particular in IKEv2 clustering. An >> earlier document, "IPsec Cluster Problem Statement", enumerates the >> issues encountered in the IKEv2/IPsec HA cluster environment. This >> document attempts to resolve these issues with the least possible >> change to the protocol. >>=20 >> This document proposes an extension to the IKEv2 protocol to solve >> the main issues of "IPsec Cluster Problem Statement" in the commonly >> deployed hot-standby cluster, and provides implementation advice for >> other issues. The main issues to be solved are the synchronization >> of IKEv2 Message ID counters, and of IPsec Replay Counters. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-= 03.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 >=20 > Scanned by Check Point Total Security Gateway. From turners@ieca.com Thu Feb 10 09:42: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 DDB393A6A5D for ; Thu, 10 Feb 2011 09:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 afOlMEsps9Rq for ; Thu, 10 Feb 2011 09:42:16 -0800 (PST) Received: from nm12-vm0.bullet.mail.ne1.yahoo.com (nm12-vm0.bullet.mail.ne1.yahoo.com [98.138.91.51]) by core3.amsl.com (Postfix) with SMTP id BCC2E3A6A50 for ; Thu, 10 Feb 2011 09:42:15 -0800 (PST) Received: from [98.138.90.55] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 10 Feb 2011 17:42:28 -0000 Received: from [98.138.87.11] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 10 Feb 2011 17:42:28 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 10 Feb 2011 17:42:28 -0000 X-Yahoo-Newman-Id: 120337.56182.bm@omp1011.mail.ne1.yahoo.com Received: (qmail 37306 invoked from network); 10 Feb 2011 17:42:27 -0000 Received: from thunderfish.local (turners@96.231.115.153 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 10 Feb 2011 09:42:27 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 1FlsOv0VM1krcRuYSks8bIugejKraGkhdtJZhXCgMN97ELF Jqyb3jnMukg6d2lO12b6_m_7NKB2cMAPwwkf.nOpPDnE0mvJS7mbee.BFGP2 VEY8MGol9XG3.USMZE.Ur2FDdScnJ764D42DRsk1cpyDpj3YjqP5vKASz43M JPMxxn2t6yWZG0Pw6xL.0IEQTRWOwB4A2ydlNVuzDvY5WbZDWYXY0GuWjnYC D9jCXjrPqjUpTSzcaiG9cA23a2aPSJK7d2iNqbCeNlWv00aHRUbpdIc8mwjQ FrWJPbpfVG.KFTCu7aQ5KGMNQuFN9s46dcQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D54237F.2070308@ieca.com> Date: Thu, 10 Feb 2011 12:42:23 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: multipart/mixed; boundary="------------070804010805070502060206" Subject: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.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: Thu, 10 Feb 2011 17:42:17 -0000 This is a multi-part message in MIME format. --------------070804010805070502060206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This might be of interest to some on this list. spt -------- Original Message -------- Subject: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt Date: Thu, 10 Feb 2011 09:00:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Suite B Profile for Internet Protocol Security (IPsec) Author(s) : K. Burgin, M. Peck Filename : draft-burgin-ipsec-suiteb-profile-00.txt Pages : 10 Date : 2011-02-10 The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-burgin-ipsec-suiteb-profile-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070804010805070502060206 Content-Type: Message/External-body; name="draft-burgin-ipsec-suiteb-profile-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-burgin-ipsec-suiteb-profile-00.txt" Content-Type: text/plain Content-ID: <2011-02-10085507.I-D@ietf.org> --------------070804010805070502060206 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070804010805070502060206-- From mpeck@mitre.org Thu Feb 10 11:21: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 6F4333A6921 for ; Thu, 10 Feb 2011 11:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6VAKLHz2A0B for ; Thu, 10 Feb 2011 11:21:20 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 522EE3A686A for ; Thu, 10 Feb 2011 11:21:20 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D7A0D21B1291 for ; Thu, 10 Feb 2011 14:21:32 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D172E21B0559 for ; Thu, 10 Feb 2011 14:21:32 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 10 Feb 2011 14:21:32 -0500 From: "Peck, Michael A" To: "ipsec@ietf.org" Date: Thu, 10 Feb 2011 14:21:32 -0500 Thread-Topic: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt Thread-Index: AcvJSeUZia9HCIDcQUeTQ2oow8epJgACrImA Message-ID: <4FD125153A070D45BC87645D3B8802880248A1F484@IMCMBX3.MITRE.ORG> References: <5946_1297359752_4D542388_5946_124519_1_4D54237F.2070308@ieca.com> In-Reply-To: <5946_1297359752_4D542388_5946_124519_1_4D54237F.2070308@ieca.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] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.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: Thu, 10 Feb 2011 19:22:05 -0000 We've submitted draft-burgin-ipsec-suiteb-profile-00.txt, Suite B Profile f= or IPsec, and would appreciate any comments. The draft should be read in conjunction with draft-law-rfc4869bis-01.txt (S= uite B Cryptographic Suites for IPsec), which has been submitted and should= be available shortly. The new RFC4869bis -01 draft removes the authentication requirements that w= ere previously in its IPsec cryptographic suite definitions. Instead, revi= sed authentication requirements have been incorporated into the Suite B Pro= file for IPsec draft. Thanks, Mike Peck -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= ean Turner Sent: Thursday, February 10, 2011 12:42 PM To: ipsec@ietf.org Subject: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt This might be of interest to some on this list. spt -------- Original Message -------- Subject: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt Date: Thu, 10 Feb 2011 09:00:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Suite B Profile for Internet Protocol Security (IPsec) Author(s) : K. Burgin, M. Peck Filename : draft-burgin-ipsec-suiteb-profile-00.txt Pages : 10 Date : 2011-02-10 The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-burgin-ipsec-suiteb-profile-00.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From paul.hoffman@vpnc.org Thu Feb 10 19:25:00 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 1C4B13A69F6 for ; Thu, 10 Feb 2011 19:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.438 X-Spam-Level: X-Spam-Status: No, score=-101.438 tagged_above=-999 required=5 tests=[AWL=0.608, 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 jDqznwZ8wGDK for ; Thu, 10 Feb 2011 19:24:54 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id AB58D3A682B for ; Thu, 10 Feb 2011 19:24:54 -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 p1B3P64h068431 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2011 20:25:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D54AC12.9040608@vpnc.org> Date: Thu, 10 Feb 2011 19:25:06 -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: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> In-Reply-To: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [IPsec] Failure Detection - issue #202 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, 11 Feb 2011 03:25:00 -0000 In reading this thread, I see Frederic saying that he is replacing text and getting some pushback, but it feels like that his text is reasonable as an addition to the security considerations. To close this issue and allow the document to go to IETF LC, I ask the authors to replace 9.2 with the following text, which is a mixture of the two proposals, with an extra paragraph break to show where the new idea starts. Yaron and I will move this to the Area Director as soon as we have a new draft. Thanks for all the work done so far! --Paul Hoffman 9.2. QCD Token Transmission A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a valid QCD token for an IKE SA which is valid on another gateway. This is true whether the attempt to trick the gateway uses the token taker's IP address or a different IP address. Because it includes the token taker's IP address in the token generation, the method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address. Note that the use of this method causes the tokens to be invalidated whenever the token taker's address changes. It is important to note that this method does not prevent revealing the QCD token to a man-in-the-middle attacker who is spoofing the token taker's IP address, if that attacker is able to direct messages to a cluster member other than the member responsible for the IKE SA. This document does not specify how a load-sharing configuration of IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members.  If an attacker can somehow access a QCD token while the SA's are still active, this attacker will be able to tear down the sessions at will. In particular, avoiding false positives is critical to the security of the proposal and a token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA. IPsec Failure Detection is thus not applicable to deployments where the QCD token is shared by multiple gateways and the gateways can not assess whether the token can be legitimately sent in the clear while another gateway may actually still own the SA's. Load balancer designs typically fall in this category. From paul.hoffman@vpnc.org Thu Feb 10 19:56: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 E5F083A6A40 for ; Thu, 10 Feb 2011 19:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.282 X-Spam-Level: X-Spam-Status: No, score=-100.282 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_40=-0.185, 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 G0pJoX43wmVZ for ; Thu, 10 Feb 2011 19:56:38 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 88F673A6A43 for ; Thu, 10 Feb 2011 19:56:38 -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 p1B3upQJ069736 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2011 20:56:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D54B383.1090806@vpnc.org> Date: Thu, 10 Feb 2011 19:56:51 -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: <20110208194502.32308.76943.idtracker@localhost> <4D51A453.1010802@gmail.com> In-Reply-To: <4D51A453.1010802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-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: Fri, 11 Feb 2011 03:56:44 -0000 On 2/8/11 12:15 PM, Yaron Sheffer wrote: > Hi, > > this version attempts to address all the open issues that were raised in > the last few months. In particular, it clarifies the behavior of the IKE > Message ID during failover while reducing some of the complexity. > Another significant change is the semantics of the IPsec replay counter > sync message. > > Please review the document. We would like to close the issues in the next > week or so, and move to WGLC. The currently open issues are here: > http://tools.ietf.org/wg/ipsecme/trac/query?status=new&status=assigned&status=reopened&component=ipsecha-protocol +1 to "Please review the document". It would be a bummer to go into WG LC and then have people find things that take major revision. --Paul Hoffman From priikone@iki.fi Thu Feb 10 21:31:17 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 4ADAF3A6B07 for ; Thu, 10 Feb 2011 21:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZRCWSdAmsID for ; Thu, 10 Feb 2011 21:31:11 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id 4ADAB3A6848 for ; Thu, 10 Feb 2011 21:31:09 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id 5874048AC; Fri, 11 Feb 2011 06:32:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id 52E1A4890; Fri, 11 Feb 2011 06:32:47 +0100 (CET) Date: Fri, 11 Feb 2011 06:32:46 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Yaron Sheffer In-Reply-To: <4D51A453.1010802@gmail.com> Message-ID: References: <20110208194502.32308.76943.idtracker@localhost> <4D51A453.1010802@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-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: Fri, 11 Feb 2011 05:31:17 -0000 On Tue, 8 Feb 2011, Yaron Sheffer wrote: : Date: Tue, 08 Feb 2011 22:15:15 +0200 : From: Yaron Sheffer : To: ipsec@ietf.org : Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-03.txt : : Hi, : : this version attempts to address all the open issues that were raised in : the last few months. In particular, it clarifies the behavior of the IKE : Message ID during failover while reducing some of the complexity. : Another significant change is the semantics of the IPsec replay counter : sync message. : : Pleas review the document. We would like to close the issues in the next : week or so, and move to WGLC. The currently open issues are here: : http://tools.ietf.org/wg/ipsecme/trac/query?status=new&status=assigned&status=reopened&component=ipsecha-protocol : Looks good to me, I have no major gripes. Ignoring the corner cases described in section 8.3 is one way to go and is fine with me. Perhaps I'd make the language of using the INVALID_SPI "SHOULD" (or "MAY") from "would" as in RFC 5996 use of INVALID_SPI is only MAY and other crash recovery mechanisms doesn't exist. Developers may face the issues we discussed on the mailing list and that discussion provides a nice reference on how to solve those issues if they are important to the developer. I'd also perhaps look the way the word "reject" has been used, sometimes used as is, sometimes written as "reject/drop", and sometimes replaced with phrase "be silently dropped". Example in section 5.1: o The peer MUST reject any received synchronization message if M1 is lower than or equal to the highest value it has seen from the cluster. This includes any previous received synchronization messages. Later in same section: o The request contains a Nonce field. This field MUST be returned in the response, unchanged. A response MUST be silently dropped if the received Nonce does not match the one that was sent. I'd assume the reject here would also result into silently dropping. RFC 5996 often uses word reject but almost always followed by what to do after the rejection. Pekka From yaronf.ietf@gmail.com Thu Feb 10 22:48: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 EC8853A6891 for ; Thu, 10 Feb 2011 22:48:27 -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=[BAYES_00=-2.599, 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 ZwSivRKGthyR for ; Thu, 10 Feb 2011 22:48:26 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C19DD3A6881 for ; Thu, 10 Feb 2011 22:48:25 -0800 (PST) Received: by fxm9 with SMTP id 9so2749474fxm.31 for ; Thu, 10 Feb 2011 22:48:39 -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 :content-transfer-encoding; bh=JAko/+nIksDjKv7Qi0C1xo699tewLLGn27fIf18SjrY=; b=YS5zQINLu4CjKIZo8tkHnCYi5MjFs69GInE9hQIPLfAZ8mDEfR2ly6E3eOXiVEdD15 EPhPo9jaocJ1IE3cQ8ciZu8k7ucW1hxayC+u2tydpwahAjaZ6FgLNm6zmbE4a6QXLrEy ePZmQPSM7pjKdB8giEdhHIkYMbgNMW3cFgdu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=OdSBQgG/Y3Ffu/tSn1ElLmPGDqonIQw1gO283SrWpnk0fSPgNZF0wp5WJR+65qiEVg kRtldVWrIYmXnWkCt/bPtmD/ya7qyeCtQI86ktI4YTjybQLSm/Jr07iZHTVRViAKhPUB DGXaBguQiB45s/8B8c2L9VwZDuTLoe0kfIW5Q= Received: by 10.223.104.147 with SMTP id p19mr117955fao.6.1297406919324; Thu, 10 Feb 2011 22:48:39 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id o17sm168462fal.25.2011.02.10.22.48.38 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 22:48:38 -0800 (PST) Message-ID: <4D54DBC4.7040907@gmail.com> Date: Fri, 11 Feb 2011 08:48:36 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Pekka Riikonen References: <20110208194502.32308.76943.idtracker@localhost> <4D51A453.1010802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-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: Fri, 11 Feb 2011 06:48:28 -0000 Hi Pekka, I agree with both of your comments, we should look at them for -04. Thanks, Yaron On 02/11/2011 07:32 AM, Pekka Riikonen wrote: > On Tue, 8 Feb 2011, Yaron Sheffer wrote: > > : Date: Tue, 08 Feb 2011 22:15:15 +0200 > : From: Yaron Sheffer > : To: ipsec@ietf.org > : Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-03.txt > : > : Hi, > : > : this version attempts to address all the open issues that were raised in > : the last few months. In particular, it clarifies the behavior of the IKE > : Message ID during failover while reducing some of the complexity. > : Another significant change is the semantics of the IPsec replay counter > : sync message. > : > : Pleas review the document. We would like to close the issues in the next > : week or so, and move to WGLC. The currently open issues are here: > : http://tools.ietf.org/wg/ipsecme/trac/query?status=new&status=assigned&status=reopened&component=ipsecha-protocol > : > Looks good to me, I have no major gripes. Ignoring the corner cases > described in section 8.3 is one way to go and is fine with me. Perhaps > I'd make the language of using the INVALID_SPI "SHOULD" (or "MAY") from > "would" as in RFC 5996 use of INVALID_SPI is only MAY and other crash > recovery mechanisms doesn't exist. Developers may face the issues we > discussed on the mailing list and that discussion provides a nice > reference on how to solve those issues if they are important to the > developer. > > I'd also perhaps look the way the word "reject" has been used, sometimes > used as is, sometimes written as "reject/drop", and sometimes replaced > with phrase "be silently dropped". Example in section 5.1: > > o The peer MUST reject any received synchronization message if M1 is > lower than or equal to the highest value it has seen from the > cluster. This includes any previous received synchronization > messages. > > Later in same section: > > o The request contains a Nonce field. This field MUST be returned > in the response, unchanged. A response MUST be silently dropped > if the received Nonce does not match the one that was sent. > > I'd assume the reject here would also result into silently dropping. RFC > 5996 often uses word reject but almost always followed by what to do after > the rejection. > > Pekka From dharkins@lounge.org Fri Feb 11 00:16:38 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 268713A6BCE for ; Fri, 11 Feb 2011 00:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 M5s+xnw0Ro6o for ; Fri, 11 Feb 2011 00:16:33 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id DBF0E3A6BD2 for ; Fri, 11 Feb 2011 00:16:31 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 191EC1022400A; Fri, 11 Feb 2011 00:16:45 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 11 Feb 2011 00:16:45 -0800 (PST) Message-ID: In-Reply-To: <4FD125153A070D45BC87645D3B8802880248A1F484@IMCMBX3.MITRE.ORG> References: <5946_1297359752_4D542388_5946_124519_1_4D54237F.2070308@ieca.com> <4FD125153A070D45BC87645D3B8802880248A1F484@IMCMBX3.MITRE.ORG> Date: Fri, 11 Feb 2011 00:16:45 -0800 (PST) From: "Dan Harkins" To: "Peck, Michael A" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 08:16:40 -0000 Hello, I have a couple of comments after a quick read. - instead of mentioning vague things like the "Diffie-Hellman common value" and the "x value", I think it would improve the draft to note that the shared result of a successful ECDH exchange will be a point (x,y) on the elliptic curve with x- and y-coordinates that satisfy the equation of the curve. Then I think it would be better to say that the the secret used in computation of SKEYSEED is the x-coordinate, treated as an unsigned integer, and represented as an octet string per section 6.2 of RFC 6090. - section 6 of this draft mentions additional requirements. This draft may be necessary but it certainly is not sufficient for an IPsec implementation to claim "Suite B compliance". There are other requirements set out by various US government agencies that dictate whether a particular implementation can be so blessed or not. In other words, this draft is not a complete and authoritative statement on what it means to be "Suite B compliant". That being the case, the following statement does not seem technical and, while it may be true when considering the other requirements for "Suite B compliance" (that come out of US government agencies), seems out-of-place and unnecessary here in an IETF document: "Suite B IPsec compliant systems MUST support IKEv2 and MUST NOT use IKEv1." The various US government agencies that deem "Suite B compliance" may forbid IKEv1 but it does not seem to be reason for an IETF document to forbid an IKEv1 implementation from deciding to use P-256 (P-384) with ECDH and ECDSA, and SHA256 (SHA384) and, in all other respects, be compliant with this draft. I feel the language in the draft is too restrictive and suggest it be removed (from section 6 and similar wording in section 1). "IKE" is referred to in other places in the draft. Just leave it at that and leave the statements of what it means to have "Suite B compliance" to the agency(-ies) that actually do that. regards, Dan. On Thu, February 10, 2011 11:21 am, Peck, Michael A wrote: > We've submitted draft-burgin-ipsec-suiteb-profile-00.txt, Suite B Profile > for IPsec, and would appreciate any comments. > > The draft should be read in conjunction with draft-law-rfc4869bis-01.txt > (Suite B Cryptographic Suites for IPsec), which has been submitted and > should be available shortly. > > The new RFC4869bis -01 draft removes the authentication requirements that > were previously in its IPsec cryptographic suite definitions. Instead, > revised authentication requirements have been incorporated into the Suite > B Profile for IPsec draft. > > Thanks, > Mike Peck > > > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Thursday, February 10, 2011 12:42 PM > To: ipsec@ietf.org > Subject: [IPsec] Fwd: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt > > This might be of interest to some on this list. > > spt > > -------- Original Message -------- > Subject: I-D Action:draft-burgin-ipsec-suiteb-profile-00.txt > Date: Thu, 10 Feb 2011 09:00:01 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Suite B Profile for Internet Protocol Security (IPsec) > Author(s) : K. Burgin, M. Peck > Filename : draft-burgin-ipsec-suiteb-profile-00.txt > Pages : 10 > Date : 2011-02-10 > > The United States Government has published guidelines for "NSA > Suite B Cryptography" dated July, 2005, which defines cryptographic > algorithm policy for national security applications. This document > specifies the conventions for using Suite B cryptography in IP > Security (IPsec). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-burgin-ipsec-suiteb-profile-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Fri Feb 11 01:55:53 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 5758E3A688F for ; Fri, 11 Feb 2011 01:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 GHSYJHhV3feq for ; Fri, 11 Feb 2011 01:55:52 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 15E413A6860 for ; Fri, 11 Feb 2011 01:55:51 -0800 (PST) X-CheckPoint: {4D5507B5-20000-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 p1B9u40J028464; Fri, 11 Feb 2011 11:56:04 +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; Fri, 11 Feb 2011 11:56:04 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 11 Feb 2011 11:56:04 +0200 From: Yoav Nir To: Paul Hoffman Date: Fri, 11 Feb 2011 11:56:03 +0200 Thread-Topic: [IPsec] Failure Detection - issue #202 Thread-Index: AcvJ0eUp+yNZrQE8Sg+kEV9vn/Ykdw== Message-ID: References: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> <4D54AC12.9040608@vpnc.org> In-Reply-To: <4D54AC12.9040608@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] Failure Detection - issue #202 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, 11 Feb 2011 09:55:53 -0000 Done. On Feb 11, 2011, at 5:25 AM, Paul Hoffman wrote: > In reading this thread, I see Frederic saying that he is replacing text=20 > and getting some pushback, but it feels like that his text is reasonable= =20 > as an addition to the security considerations. >=20 > To close this issue and allow the document to go to IETF LC, I ask the=20 > authors to replace 9.2 with the following text, which is a mixture of=20 > the two proposals, with an extra paragraph break to show where the new=20 > idea starts. Yaron and I will move this to the Area Director as soon as=20 > we have a new draft. Thanks for all the work done so far! >=20 > --Paul Hoffman On Feb 11, 2011, at 11:54 AM, IETF I-D Submission Tool wrote: >=20 > A new version of I-D, draft-ietf-ipsecme-failure-detection-04.txt has bee= n successfully submitted by Yoav Nir and posted to the IETF repository. >=20 > Filename: draft-ietf-ipsecme-failure-detection > Revision: 04 > Title: A Quick Crash Detection Method for IKE > Creation_date: 2011-02-11 > WG ID: ipsecme > Number_of_pages: 23 >=20 > Abstract: > This document describes an extension to the IKEv2 protocol that > allows for faster detection of SA desynchronization using a saved > token. >=20 > 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. >=20 >=20 >=20 > The IETF Secretariat. From Internet-Drafts@ietf.org Fri Feb 11 02:00:03 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 0AB883A6860; Fri, 11 Feb 2011 02:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 7J8C0Xp2h0Yu; Fri, 11 Feb 2011 02:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B805C3A6A63; Fri, 11 Feb 2011 02:00:01 -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.12 Message-ID: <20110211100001.6688.57835.idtracker@localhost> Date: Fri, 11 Feb 2011 02:00:01 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 10:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-04.txt Pages : 23 Date : 2011-02-11 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-11015432.I-D@ietf.org> --NextPart-- From kivinen@iki.fi Fri Feb 11 03:37:53 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 C06033A68B7 for ; Fri, 11 Feb 2011 03:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 2KDhh08eCBEJ for ; Fri, 11 Feb 2011 03:37:50 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 80A023A694F for ; Fri, 11 Feb 2011 03:37:49 -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 p1BBc04W002150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Feb 2011 13:38:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p1BBbxq7021913; Fri, 11 Feb 2011 13:37:59 +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: <19797.8087.173131.553579@fireball.kivinen.iki.fi> Date: Fri, 11 Feb 2011 13:37:59 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <4D54AC12.9040608@vpnc.org> References: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> <4D54AC12.9040608@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Failure Detection - issue #202 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, 11 Feb 2011 11:37:53 -0000 Paul Hoffman writes: > 9.2. QCD Token Transmission > > A token maker MUST NOT send a valid QCD token in an unprotected > message for an existing IKE SA. > > This requirement is obvious and easy in the case of a single gateway. > However, some implementations use a load balancer to divide the load > between several physical gateways. It MUST NOT be possible even in > such a configuration to trick one gateway into sending a valid QCD > token for an IKE SA which is valid on another gateway. This is true > whether the attempt to trick the gateway uses the token taker's IP > address or a different IP address. > > Because it includes the token taker's IP address in the token > generation, the method in Section 5.2 prevents revealing the QCD > token for an existing pair of IKE SPIs to an attacker who is using a > different IP address. Note that the use of this method causes the > tokens to be invalidated whenever the token taker's address changes. > It is important to note that this method does not prevent revealing > the QCD token to a man-in-the-middle attacker who is spoofing the > token taker's IP address, if that attacker is able to direct messages > to a cluster member other than the member responsible for the IKE SA. > > This document does not specify how a load-sharing configuration of > IPsec gateways would work, but in order to support this > specification, all members MUST be able to tell whether a particular > IKE SA is active anywhere in the cluster. One way to do it is to > synchronize a list of active IKE SPIs among all the cluster members. > > If an attacker can somehow access a QCD token while the SA's are > still active, this attacker will be able to tear down the sessions at > will. In particular, avoiding false positives is critical to the > security of the proposal and a token maker MUST NOT send a QCD token > in an unprotected message for an existing IKE SA. IPsec Failure > Detection is thus not applicable to deployments where the QCD token > is shared by multiple gateways and the gateways can not assess > whether the token can be legitimately sent in the clear while another > gateway may actually still own the SA's. Load balancer designs > typically fall in this category. I think the section is bit confusing. It says similar (or perhaps same, I am not sure) things in different places using different words, so it is not really clear what it is saying. In general I think that section needs rewrite, and the problem is that nobody really has real overall picture what should be in it, so it is just cut & paste text from different authors with no overall structure. For example it says twice that "token maker MUST NOT send a (valid) QCD token in an unprotected message for an existing IKE SA." The first uses "valid QCD token", another says "a QCD token", not sure if there are supposed to be any difference there. -- kivinen@iki.fi From wierbows@us.ibm.com Fri Feb 11 07:08:42 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 9100A3A6A19; Fri, 11 Feb 2011 07:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjQC8nL5Wug1; Fri, 11 Feb 2011 07:08:41 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 3B8BC3A69BD; Fri, 11 Feb 2011 07:08:41 -0800 (PST) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1BEknfD027303; Fri, 11 Feb 2011 09:50:14 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 0021872806D; Fri, 11 Feb 2011 10:08:45 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1BF8hJF2429162; Fri, 11 Feb 2011 10:08:45 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1BF8gfN022614; Fri, 11 Feb 2011 10:08:43 -0500 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p1BF8gkh022591; Fri, 11 Feb 2011 10:08:42 -0500 In-Reply-To: <19797.8087.173131.553579@fireball.kivinen.iki.fi> References: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> <4D54AC12.9040608@vpnc.org> <19797.8087.173131.553579@fireball.kivinen.iki.fi> X-KeepSent: 40C7B0EA:83EA1423-85257834:004F6432; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: David Wierbowski Date: Fri, 11 Feb 2011 10:08:40 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.5.2FP1|November 29, 2010) at 02/11/2011 10:08:41 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Paul Hoffman Subject: Re: [IPsec] Failure Detection - issue #202 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, 11 Feb 2011 15:08:42 -0000 I agree with Tero that the section is confusing and very difficult to follow. I have taken a stab at rewording it. I think this still incorporates the blending of the two approaches that Paul attempted, but flows better and makes it easier to understand. I'm not sure it addresses all of Tero's concerns, but I hope it gets us closer. A token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. In such configuration it MUST NOT be possible to trick one gateway into sending a QCD token for an IKE SA which exists on another gateway. This is true whether the an attacker uses the token taker's IP address or a different IP address. Because it includes the token taker's IP address in the token generation, the method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address. Note that the use of this method causes the tokens to be invalidated whenever the token taker's address changes. It is also important to note that this method does not prevent revealing the QCD token to a man-in-the-middle attacker who is spoofing the token taker's IP address. Such an attacker may attempt to direct messages to a cluster member other than the member responsible for the IKE SA in an attempt to trick that gateway into sending a QCD token for an existing IKE SA. IPsec Failure Detection is not applicable to deployments where the QCD token is shared by multiple gateways and the gateways cannot assess whether the token can be legitimately sent in the clear while another gateway may actually still own the SA's. Load balancer configurations typically fall in this category. In order for a load balancing configuration of IPsec gateways to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 From: Tero Kivinen To: Paul Hoffman Cc: ipsec@ietf.org Date: 02/11/2011 06:38 AM Subject: Re: [IPsec] Failure Detection - issue #202 Sent by: ipsec-bounces@ietf.org Paul Hoffman writes: > 9.2. QCD Token Transmission > > A token maker MUST NOT send a valid QCD token in an unprotected > message for an existing IKE SA. > > This requirement is obvious and easy in the case of a single gateway. > However, some implementations use a load balancer to divide the load > between several physical gateways. It MUST NOT be possible even in > such a configuration to trick one gateway into sending a valid QCD > token for an IKE SA which is valid on another gateway. This is true > whether the attempt to trick the gateway uses the token taker's IP > address or a different IP address. > > Because it includes the token taker's IP address in the token > generation, the method in Section 5.2 prevents revealing the QCD > token for an existing pair of IKE SPIs to an attacker who is using a > different IP address. Note that the use of this method causes the > tokens to be invalidated whenever the token taker's address changes. > It is important to note that this method does not prevent revealing > the QCD token to a man-in-the-middle attacker who is spoofing the > token taker's IP address, if that attacker is able to direct messages > to a cluster member other than the member responsible for the IKE SA. > > This document does not specify how a load-sharing configuration of > IPsec gateways would work, but in order to support this > specification, all members MUST be able to tell whether a particular > IKE SA is active anywhere in the cluster. One way to do it is to > synchronize a list of active IKE SPIs among all the cluster members. > > If an attacker can somehow access a QCD token while the SA's are > still active, this attacker will be able to tear down the sessions at > will. In particular, avoiding false positives is critical to the > security of the proposal and a token maker MUST NOT send a QCD token > in an unprotected message for an existing IKE SA. IPsec Failure > Detection is thus not applicable to deployments where the QCD token > is shared by multiple gateways and the gateways can not assess > whether the token can be legitimately sent in the clear while another > gateway may actually still own the SA's. Load balancer designs > typically fall in this category. I think the section is bit confusing. It says similar (or perhaps same, I am not sure) things in different places using different words, so it is not really clear what it is saying. In general I think that section needs rewrite, and the problem is that nobody really has real overall picture what should be in it, so it is just cut & paste text from different authors with no overall structure. For example it says twice that "token maker MUST NOT send a (valid) QCD token in an unprotected message for an existing IKE SA." The first uses "valid QCD token", another says "a QCD token", not sure if there are supposed to be any difference there. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Fri Feb 11 08:20:22 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 E9D5B3A69C9 for ; Fri, 11 Feb 2011 08:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=0.617, 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 bpts9G9NERV0 for ; Fri, 11 Feb 2011 08:20:21 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D7CFD3A69BE for ; Fri, 11 Feb 2011 08:20:20 -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 p1BGKYYg002068 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 11 Feb 2011 09:20:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D5561D3.7090609@vpnc.org> Date: Fri, 11 Feb 2011 08:20:35 -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: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> <4D54AC12.9040608@vpnc.org> <19797.8087.173131.553579@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Failure Detection - issue #202 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, 11 Feb 2011 16:20:22 -0000 On 2/11/11 7:08 AM, David Wierbowski wrote: > I agree with Tero that the section is confusing and very difficult to > follow. FWIW, I thought the wording I presented was repetitive but not confusing. "Repetitive" is not necessarily a bad thing for security considerations, but confusing is. I have taken a stab at rewording it. I think this still > incorporates the blending of the two approaches that Paul attempted, but > flows better and makes it easier to understand. I'm not sure it addresses > all of Tero's concerns, but I hope it gets us closer. > > A token maker MUST NOT send a QCD token in an unprotected > message for an existing IKE SA. > > This requirement is obvious and easy in the case of a single gateway. > However, some implementations use a load balancer to divide the load > between several physical gateways. In such configuration it MUST NOT > be possible to trick one gateway into sending a QCD token for an > IKE SA which exists on another gateway. This is true whether the > an attacker uses the token taker's IP address or a different IP > address. > > Because it includes the token taker's IP address in the token > generation, the method in Section 5.2 prevents revealing the QCD > token for an existing pair of IKE SPIs to an attacker who is using a > different IP address. Note that the use of this method causes the > tokens to be invalidated whenever the token taker's address changes. > It is also important to note that this method does not prevent > revealing the QCD token to a man-in-the-middle attacker who is > spoofing the token taker's IP address. Such an attacker may attempt > to direct messages to a cluster member other than the member > responsible for the IKE SA in an attempt to trick that gateway into > sending a QCD token for an existing IKE SA. > > IPsec Failure Detection is not applicable to deployments where the QCD > token is shared by multiple gateways and the gateways cannot assess > whether the token can be legitimately sent in the clear while another > gateway may actually still own the SA's. Load balancer configurations > typically fall in this category. In order for a load balancing > configuration of IPsec gateways to support this specification, > all members MUST be able to tell whether a particular IKE SA is active > anywhere in the cluster. One way to do it is to synchronize a list of > active IKE SPIs among all the cluster members. OK, let's have an extra round before we go to IETF Last Call. If no one disagrees with Dave's new wording before Tuesday, Feb 15, I will ask the authors to put it in a new draft. --Paul Hoffman From yaronf.ietf@gmail.com Fri Feb 11 13:05: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 708173A69DA; Fri, 11 Feb 2011 13:05:29 -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=[BAYES_00=-2.599, 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 taCXQUAjwWZV; Fri, 11 Feb 2011 13:05:28 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B788E3A67B3; Fri, 11 Feb 2011 13:05:27 -0800 (PST) Received: by fxm9 with SMTP id 9so3613508fxm.31 for ; Fri, 11 Feb 2011 13:05:42 -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 :content-transfer-encoding; bh=cvNl19M/srth74vU+IiEN8T3f05h9dm03sFzhihjTbE=; b=lYBiR5WzODbVoM3Prelh7NqwIEljsgv8/tyTlP29362Ae29AZ2BrUl9nMfsk8aOuwh keGX/DQ3r8cBUEUpSSna4WxnK+ZcXHHpuEHHzFc//ywq3QjCYslHtTWCLDAS76E44cSF H91tpa4IikzsRiEICMgW8uzYqKJsj3ckhoXBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wcDsi3NFepjRZCZDy9MOj2cpiAD/ZZjSlQYXjvWllrlV3kN3vS4hLhjxkfW+SXDm4x YyaE6I0GlmaCjqhzwiy223bZFyJLkNWa3sl+YYjALf3G4ZxwIB8j56DNYU7Sm6JPa05B nkYb4X/7PTjoVvo8nOLQ9xrg1m1UOUzzQANSc= Received: by 10.223.79.1 with SMTP id n1mr1017147fak.36.1297458341988; Fri, 11 Feb 2011 13:05:41 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id e6sm620418fav.8.2011.02.11.13.05.40 (version=SSLv3 cipher=OTHER); Fri, 11 Feb 2011 13:05:41 -0800 (PST) Message-ID: <4D55A4A2.7020900@gmail.com> Date: Fri, 11 Feb 2011 23:05:38 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Security consideration for DTLS: Adversarial packet loss/reordering 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, 11 Feb 2011 21:05:29 -0000 Hi Steve, [Cross-posted to ipsecme] I have always wondered about these sequence numbers, and the concept of anti-replay in IPsec. - IPsec is architecturally a "plug-in replacement" for IP. And IP allows for arbitrary packet deletion, duplication and reordering. - Anti-replay counters are giving us no end of trouble in clustered environments (e.g. http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsecha-protocol/). - IPsec (unfortunately) does not have an application API, at least in most implementations. Such an API might indeed have put this feature to good use. - And lastly, IPsec anti-replay is optional, which signifies to me that it's always been an iffy feature. I have looked at RFC 4301 again (the IPsec architecture), and it provides only weak justification for this feature. Can you please point me to a more convincing reasoning? Thanks, Yaron > ------------------------------ > > Message: 2 > Date: Thu, 10 Feb 2011 19:51:08 -0500 > From: Steven Bellovin > Subject: Re: [TLS] Security consideration for DTLS: Adversarial packet > loss/reordering > To: Eric Rescorla > Cc: Paul Hoffman, tls@ietf.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On Feb 10, 2011, at 3:03 21PM, Eric Rescorla wrote: > >> On Thu, Feb 10, 2011 at 12:03 PM, Eric Rescorla wrote: >>> On Thu, Feb 10, 2011 at 11:31 AM, Paul Hoffman wrote: >>>> On 2/10/11 9:49 AM, Matt McCutchen wrote: >>>>> >>>>> Here's an issue that might be worth adding as a security consideration >>>>> in the next version of the DTLS specification. It may affect IPsec too; >>>>> I haven't looked into that. Thoughts? >>>> >>>> I disagree with this suggestion, at least as it is proposed. >>>> >>>>> DTLS does not prevent an attacker from dropping or reordering records. >>>>> Datagram applications are generally designed to tolerate random packet >>>>> loss and reordering, but care must be taken to ensure that adversarial >>>>> loss and reordering cannot break the desired higher-level security >>>>> properties. >>>> >>>> That "care" sounds like it is care in the DTLS-using protocol, but no >>>> suggestion is given how such a protocol can show care. This makes the >>>> suggestion little more than "be careful", which is not useful. >>> >>> DTLS does deliver order information, of course. It just doesn't impose >>> reordering. >>> >>> Perhaps the take-home for DTLS itself is that it would be nice if >>> packets came with >>> their sequence numbers attached. >>> >> >> In the API, I mean. >> > Given the importance of sequence numbers for IPsec, I very much agree. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From kivinen@iki.fi Mon Feb 14 05:14:03 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 358B13A6D20 for ; Mon, 14 Feb 2011 05:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 5-Q4-x9iHc2K for ; Mon, 14 Feb 2011 05:14:01 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 677433A6A6C for ; Mon, 14 Feb 2011 05:14:01 -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 p1EDEINO019720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Feb 2011 15:14:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p1EDEHDx002063; Mon, 14 Feb 2011 15:14:17 +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: <19801.10921.146517.964692@fireball.kivinen.iki.fi> Date: Mon, 14 Feb 2011 15:14:17 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <4D5561D3.7090609@vpnc.org> References: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> <4D54AC12.9040608@vpnc.org> <19797.8087.173131.553579@fireball.kivinen.iki.fi> <4D5561D3.7090609@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 14 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Failure Detection - issue #202 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, 14 Feb 2011 13:14:03 -0000 Paul Hoffman writes: > > A token maker MUST NOT send a QCD token in an unprotected > > message for an existing IKE SA. > > > > This requirement is obvious and easy in the case of a single gateway. > > However, some implementations use a load balancer to divide the load > > between several physical gateways. In such configuration it MUST NOT > > be possible to trick one gateway into sending a QCD token for an > > IKE SA which exists on another gateway. This is true whether the > > an attacker uses the token taker's IP address or a different IP > > address. > > > > Because it includes the token taker's IP address in the token > > generation, the method in Section 5.2 prevents revealing the QCD > > token for an existing pair of IKE SPIs to an attacker who is using a > > different IP address. I think this paragraph should be reformatted to include Section 5.2 in the beginning, so it would emphasize that this is case 1, i.e: The method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address by including the token taker's IP addres in the token generation. > > Note that the use of this method causes the > > tokens to be invalidated whenever the token taker's address changes. I am not sure that this paragraph belongs here, as it should already be mentioned in the section 5.2 and this is not a security issue.. I would remove the whole paragraph. > > It is also important to note that this method does not prevent > > revealing the QCD token to a man-in-the-middle attacker who is > > spoofing the token taker's IP address. Such an attacker may attempt > > to direct messages to a cluster member other than the member > > responsible for the IKE SA in an attempt to trick that gateway into > > sending a QCD token for an existing IKE SA. I think removing things like "It is also important to note ..." type of text, as they do not really help understanding the problem, i.e: This method does not prevent revealing the QCD token to a active attacker who is spoofing the token taker's IP address. Such an attacker may attempt to direct messages to a cluster member other than the member responsible for the IKE SA in an attempt to trick that gateway into sending QCD token for an existing IKE SA. (Also replaced man-in-the-middle as the attacker is not necessarely man-in-the-middle (http://en.wikipedia.org/wiki/Man-in-the-middle_attack) but instead simply active attacker sending faked packets). > > IPsec Failure Detection is not applicable to deployments where the QCD > > token is shared by multiple gateways and the gateways cannot assess > > whether the token can be legitimately sent in the clear while another > > gateway may actually still own the SA's. Load balancer configurations > > typically fall in this category. In order for a load balancing > > configuration of IPsec gateways to support this specification, > > all members MUST be able to tell whether a particular IKE SA is active > > anywhere in the cluster. One way to do it is to synchronize a list of > > active IKE SPIs among all the cluster members. I think this paragraph should perhaps be before the text about section 5.2, as this is more generic. > OK, let's have an extra round before we go to IETF Last Call. If no one > disagrees with Dave's new wording before Tuesday, Feb 15, I will ask the > authors to put it in a new draft. Actually by reading the section 5.2 text, it is does not give any way to actually safely use section 5.2 token generation in load balancing cases. I think people who wanted the section 5.2 text here wanted to actually use it in load balancing cases, and in their setup it was made impossible to forward packets with one load balancing gateways destination address to another gateway, i.e. made it impossible for the attacker to trick gateway sending QCD token for an existing IKE SA. -- kivinen@iki.fi From smoonen@us.ibm.com Mon Feb 14 09:13: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 9BFCF3A6A0F; Mon, 14 Feb 2011 09:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[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 I8Hvg4oORSnb; Mon, 14 Feb 2011 09:13:24 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 87E853A6D48; Mon, 14 Feb 2011 09:13:24 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1EGsYOI013485; Mon, 14 Feb 2011 11:55:05 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id F373C4DE803E; Mon, 14 Feb 2011 12:12:43 -0500 (EST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1EHDgmm474358; Mon, 14 Feb 2011 12:13:43 -0500 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 p1EHDgOq022659; Mon, 14 Feb 2011 10:13:42 -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 p1EHDgBD022646; Mon, 14 Feb 2011 10:13:42 -0700 In-Reply-To: <19801.10921.146517.964692@fireball.kivinen.iki.fi> References: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> <4D54AC12.9040608@vpnc.org> <19797.8087.173131.553579@fireball.kivinen.iki.fi> <4D5561D3.7090609@vpnc.org> <19801.10921.146517.964692@fireball.kivinen.iki.fi> X-KeepSent: 780CB023:BF457D1D-85257837:005D7845; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Mon, 14 Feb 2011 12:07:42 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 02/14/2011 10:13:41 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF2A4DFCEFED58f9e8a93df938690918c0ABBF2A4DFCEFED5" X-Content-Scanned: Fidelis XPS MAILER Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Paul Hoffman Subject: Re: [IPsec] Failure Detection - issue #202 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, 14 Feb 2011 17:13:26 -0000 --0__=0ABBF2A4DFCEFED58f9e8a93df938690918c0ABBF2A4DFCEFED5 Content-type: multipart/alternative; Boundary="1__=0ABBF2A4DFCEFED58f9e8a93df938690918c0ABBF2A4DFCEFED5" --1__=0ABBF2A4DFCEFED58f9e8a93df938690918c0ABBF2A4DFCEFED5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I'm ok with Dave's proposed text, with or without Tero's proposed chang= es. Apologies for missing the fact that it is not strictly man-in-the-middl= e attack. Certainly the attacker won't be able to take advantage of the revelation if he is not in the middle, but it's still improper to revea= l the token. I share Tero's concern with the general usefulness of Section 5.2. I th= ink it's fine to keep it there, but I agree that his "made impossible" observation is absolutely essential for its use. That was the motivatio= n behind my "important to note," although I am ok with removing that phra= se. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Paul Hoffman Cc: ipsec@ietf.org Date: 02/14/2011 08:14 AM Subject: Re: [IPsec] Failure Detection - issue #202 Sent by: ipsec-bounces@ietf.org Paul Hoffman writes: > > A token maker MUST NOT send a QCD token in an unprotected > > message for an existing IKE SA. > > > > This requirement is obvious and easy in the case of a single gatewa= y. > > However, some implementations use a load balancer to divide the loa= d > > between several physical gateways. In such configuration it MUST N= OT > > be possible to trick one gateway into sending a QCD token for an > > IKE SA which exists on another gateway. This is true whether the > > an attacker uses the token taker's IP address or a different IP > > address. > > > > Because it includes the token taker's IP address in the token > > generation, the method in Section 5.2 prevents revealing the QCD > > token for an existing pair of IKE SPIs to an attacker who is using = a > > different IP address. I think this paragraph should be reformatted to include Section 5.2 in the beginning, so it would emphasize that this is case 1, i.e: The method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address by including the token taker's IP addres in the token generation. > > Note that the use of this method causes the > > tokens to be invalidated whenever the token taker's address changes= . I am not sure that this paragraph belongs here, as it should already be mentioned in the section 5.2 and this is not a security issue.. I would remove the whole paragraph. > > It is also important to note that this method does not prevent > > revealing the QCD token to a man-in-the-middle attacker who is > > spoofing the token taker's IP address. Such an attacker may attempt= > > to direct messages to a cluster member other than the member > > responsible for the IKE SA in an attempt to trick that gateway into= > > sending a QCD token for an existing IKE SA. I think removing things like "It is also important to note ..." type of text, as they do not really help understanding the problem, i.e: This method does not prevent revealing the QCD token to a active attacker who is spoofing the token taker's IP address. Such an attacker may attempt to direct messages to a cluster member other than the member responsible for the IKE SA in an attempt to trick that gateway into sending QCD token for an existing IKE SA. (Also replaced man-in-the-middle as the attacker is not necessarely man-in-the-middle (http://en.wikipedia.org/wiki/Man-in-the-middle_attack) but instead simply active attacker sending faked packets). > > IPsec Failure Detection is not applicable to deployments where the = QCD > > token is shared by multiple gateways and the gateways cannot assess= > > whether the token can be legitimately sent in the clear while anoth= er > > gateway may actually still own the SA's. Load balancer configuratio= ns > > typically fall in this category. In order for a load balancing > > configuration of IPsec gateways to support this specification, > > all members MUST be able to tell whether a particular IKE SA is act= ive > > anywhere in the cluster. One way to do it is to synchronize a list= of > > active IKE SPIs among all the cluster members. I think this paragraph should perhaps be before the text about section 5.2, as this is more generic. > OK, let's have an extra round before we go to IETF Last Call. If no o= ne > disagrees with Dave's new wording before Tuesday, Feb 15, I will ask = the > authors to put it in a new draft. Actually by reading the section 5.2 text, it is does not give any way to actually safely use section 5.2 token generation in load balancing cases. I think people who wanted the section 5.2 text here wanted to actually use it in load balancing cases, and in their setup it was made impossible to forward packets with one load balancing gateways destination address to another gateway, i.e. made it impossible for the attacker to trick gateway sending QCD token for an existing IKE SA. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBF2A4DFCEFED58f9e8a93df938690918c0ABBF2A4DFCEFED5 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I'm ok with Dave's proposed text, with or without Tero's proposed ch= anges.

Apologies for missing the fact that it is not strictly man-in-the-middl= e attack. Certainly the attacker won't be able to take advantage of the= revelation if he is not in the middle, but it's still improper to reve= al the token.

I share Tero's concern with the general usefulness of Section 5.2. I th= ink it's fine to keep it there, but I agree that his "made impossi= ble" observation is absolutely essential for its use. That was the= motivation behind my "important to note," although I am ok w= ith removing that phrase.


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

3D"InactiveTero Kivinen -= --02/14/2011 08:14:35 AM---Paul Hoffman writes: > > A token maker= MUST NOT send a QCD token in an unprotected

From: Tero K= ivinen <kivinen@iki.fi>
To: Paul Hof= fman <paul.hoffman@vpnc.org>
Cc: ipsec@ie= tf.org
Date: 02/14/= 2011 08:14 AM
Subject: Re:= [IPsec] Failure Detection - issue #202
Sent by: ips= ec-bounces@ietf.org




Paul Hoffman writes:
> > A token maker MUST NOT send a QCD token in an unprotected
= > > message for an existing IKE SA.
> >
> > This requirement is obvious and easy in the case of a single = gateway.
> > However, some implementations use a load balancer to divide t= he load
> > between several physical gateways.  In such configuratio= n it MUST NOT
> > be possible to trick one gateway into sending a QCD token for= an
> > IKE SA which exists on another gateway.  This is true wh= ether the
> > an attacker uses the token taker's IP address or a different = IP
> > address.
> >
> > Because it includes the token taker's IP address in the token=
> > generation, the method in Section 5.2 prevents revealing the = QCD
> > token for an existing pair of IKE SPIs to an attacker who is = using a
> > different IP address.

I think this paragraph should be reformatted to include Section 5.2 in<= br> the beginning, so it would emphasize that this is case 1, i.e:

The method in Section 5.2 prevents revealing the QCD token for
an existing pair of IKE SPIs to an attacker who is using a
different IP address by including the token taker's IP addres
in the token generation.

> > Note that the use of this method causes the
> > tokens to be invalidated whenever the token taker's address c= hanges.

I am not sure that this paragraph belongs here, as it should already be mentioned in the section 5.2 and this is not a security
issue.. I would remove the whole paragraph.

> > It is also important to note that this method does not preven= t
> > revealing the QCD token to a man-in-the-middle attacker who i= s
> > spoofing the token taker's IP address. Such an attacker may a= ttempt
> > to direct messages to a cluster member other than the member<= br> > > responsible for the IKE SA in an attempt to trick that gatewa= y into
> > sending a QCD token for an existing IKE SA.

I think removing things like "It is also important to note ...&quo= t; type
of text, as they do not really help understanding the problem, i.e:
=
This method does not prevent revealing the QCD token to a
active attacker who is spoofing the token taker's IP address.
Such an attacker may attempt to direct messages to a cluster
member other than the member responsible for the IKE SA in an
attempt to trick that gateway into sending QCD token for an
existing IKE SA.

(Also replaced man-in-the-middle as the attacker is not necessarely
= man-in-the-middle
(http://en.wikipedia.org/wiki/Man-in-the-middle_attack= ) but instead
simply active attacker sending faked packets).

> > IPsec Failure Detection is not applicable to deployments wher= e the QCD
> > token is shared by multiple gateways and the gateways cannot = assess
> > whether the token can be legitimately sent in the clear while= another
> > gateway may actually still own the SA's. Load balancer config= urations
> > typically fall in this category.  In order for a load ba= lancing
> > configuration of IPsec gateways to support this specification= ,
> > all members MUST be able to tell whether a particular IKE SA = is active
> > anywhere in the cluster.  One way to do it is to synchro= nize a list of
> > active IKE SPIs among all the cluster members.

I think this paragraph should perhaps be before the text about section<= br> 5.2, as this is more generic.

> OK, let's have an extra round before we go to IETF Last Call. If n= o one
> disagrees with Dave's new wording before Tuesday, Feb 15, I will a= sk the
> authors to put it in a new draft.

Actually by reading the section 5.2 text, it is does not give any way to actually safely use section 5.2 token generation in load balancing cases.

I think people who wanted the section 5.2 text here wanted to actually<= br> use it in load balancing cases, and in their setup it was made
impossible to forward packets with one load balancing gateways
destination address to another gateway, i.e. made it impossible for
= the attacker to trick gateway sending QCD token for an existing IKE
= SA.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBF2A4DFCEFED58f9e8a93df938690918c0ABBF2A4DFCEFED5-- --0__=0ABBF2A4DFCEFED58f9e8a93df938690918c0ABBF2A4DFCEFED5 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF2A4DFCEFED58f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF2A4DFCEFED58f9e8a93df938690918c0ABBF2A4DFCEFED5-- From paul.hoffman@vpnc.org Mon Feb 14 12:43: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 1C9653A6D46 for ; Mon, 14 Feb 2011 12:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.056 X-Spam-Level: X-Spam-Status: No, score=-100.056 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_50=0.001, 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 GIq7dFVAkszo for ; Mon, 14 Feb 2011 12:43:28 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 81C353A6C51 for ; Mon, 14 Feb 2011 12:43:28 -0800 (PST) Received: from MacBook-08.local (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1EKhpbm058353 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Feb 2011 13:43:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D599407.6030201@vpnc.org> Date: Mon, 14 Feb 2011 12:43:51 -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] Not meeting in Prague 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, 14 Feb 2011 20:43:29 -0000 Greetings again. This is just confirming what Yaron and I had said earlier, namely that the IPsecME WG will not meet in Prague. We will hopefully be done with WG LC on the HA protocol document by then, and therefore it is not worth the hassle of scheduling a meeting and so on. --Paul Hoffman From kivinen@iki.fi Tue Feb 15 05:47:53 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 1C62E3A6D29 for ; Tue, 15 Feb 2011 05:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 NkIW5dM7SaBw for ; Tue, 15 Feb 2011 05:47:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0453A6D25 for ; Tue, 15 Feb 2011 05:47:51 -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 p1FDmDCc012500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Feb 2011 15:48:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p1FDmBhF006817; Tue, 15 Feb 2011 15:48:11 +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: <19802.33819.463157.141533@fireball.kivinen.iki.fi> Date: Tue, 15 Feb 2011 15:48:11 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <042D720F-888A-44CB-8414-E145E173EC08@checkpoint.com> <4D54AC12.9040608@vpnc.org> <19797.8087.173131.553579@fireball.kivinen.iki.fi> <4D5561D3.7090609@vpnc.org> <19801.10921.146517.964692@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 24 min X-Total-Time: 32 min Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Failure Detection - issue #202 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, 15 Feb 2011 13:47:53 -0000 Scott C Moonen writes: > Apologies for missing the fact that it is not strictly man-in-the-middle > attack. Certainly the attacker won't be able to take advantage of the > revelation if he is not in the middle, but it's still improper to reveal > the token. Attacker does not need to actually even see the token, it is enough if he just manages to get it forwarded to the other end (for example using spoofed source IP addresses). I.e. lets say situation is as following: ... ... .. +---------+ . ... /--| Host B1 | +--------+ . .. +---------------+ / +---------+ | Host A |-------. Internet .---| Load Balancer |- +--------+ . . +---------------+ \ +---------+ .. ... \--| Host B2 | +----------+ /....... +---------+ | Attacker |------- +----------+ The Host A is the token taker, and Host B is load balancing cluster using Host B1 and B2, which are using same QCD secret, but separate IKE databases. Now if Attacker knows IP addresses of A and B1/B2, and IKE SPIs used between host A and Host B1, it can create valid looking IKE packet having Host A's source IP address, Host B2 destination IP address, and known IKE SPIs. The contents does not matter as host B2 cannot decrypt it. Host B will reply with packet: <-- HDR(SPIi,SPIr) N(INVALID_IKE_SPI), N(QCD_TOKEN) using source IP address of B2, and destination address of A. This packet will be automatically routed directly to A, and attacker does not even need to tell his own IP address at all while attacking. RFC 5996 says that "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet.", which means that Host A will accept that QCD_TOKEN even when it does have Host B2's IP address instead of B1's IP address, and it will tear down the IKE SA. This is why I do think man-in-the-middle is wrong term, as the attacker does not even need to see the reply packets. It is enough for attacker to see one IKE SA packet between A and B1 and know the IP address of B2 to launch the attacker, and attacker does not even need to disclose his own IP address to do the attack. -- kivinen@iki.fi From kent@bbn.com Tue Feb 15 13:55:02 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 37E8B3A6C21; Tue, 15 Feb 2011 13:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 0v-1hcecLqT4; Tue, 15 Feb 2011 13:55:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 333583A6AB9; Tue, 15 Feb 2011 13:55:01 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:56192 helo=[10.84.131.124]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PpSrn-000HQ2-Ax; Tue, 15 Feb 2011 16:55:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D55A4A2.7020900@gmail.com> References: <4D55A4A2.7020900@gmail.com> Date: Tue, 15 Feb 2011 11:34:26 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IPsecme WG , tls@ietf.org Subject: Re: [IPsec] Security consideration for DTLS: Adversarial packet loss/reordering 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, 15 Feb 2011 21:55:02 -0000 At 11:05 PM +0200 2/11/11, Yaron Sheffer wrote: >Hi Steve, > >[Cross-posted to ipsecme] > >I have always wondered about these sequence numbers, and the concept >of anti-replay in IPsec. > >- IPsec is architecturally a "plug-in replacement" for IP. And IP >allows for arbitrary packet deletion, duplication and reordering. >- Anti-replay counters are giving us no end of trouble in clustered >environments (e.g. >http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsecha-protocol/). >- IPsec (unfortunately) does not have an application API, at least >in most implementations. Such an API might indeed have put this >feature to good use. >- And lastly, IPsec anti-replay is optional, which signifies to me >that it's always been an iffy feature. > >I have looked at RFC 4301 again (the IPsec architecture), and it >provides only weak justification for this feature. Can you please >point me to a more convincing reasoning? > >Thanks, > Yaron Can any Steve reply? While IP allows arbitrary packet arrival, IPsec allows a receiver to limit the extent of such OOO arrival, to enable it to detect and reject replay attacks. That is the rationale for AR and it is just as applicable in a clustered receiver context as in a single receiver context. The fact that it is optional to use (not to implement) is NOT an indication that it is "iffy." It is an indication that not all apps might require its use, and some might find it in conflict with the app. That is a app-specific decision, not a decision to be made by an IPsec vendor. Use of this feature is declared via the SAD, so an administrative interface is one way to specify use of this feature based on the protocol and port #'s. I'm sorry that AR is causing problems in clustered contexts, but that is not a justification to not support it. Steve From Internet-Drafts@ietf.org Fri Feb 18 04:30:03 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 8ACFA3A6F29; Fri, 18 Feb 2011 04:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 h8IK0Oj5ovhs; Fri, 18 Feb 2011 04:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156523A6D63; Fri, 18 Feb 2011 04:30: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.12 Message-ID: <20110218123002.26243.29547.idtracker@localhost> Date: Fri, 18 Feb 2011 04:30:02 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 12:30: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-05.txt Pages : 23 Date : 2011-02-18 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-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-18042633.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Fri Feb 18 07:23: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 0E5CA3A6E1E for ; Fri, 18 Feb 2011 07:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.197 X-Spam-Level: X-Spam-Status: No, score=-101.197 tagged_above=-999 required=5 tests=[AWL=0.849, 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 V576rGNo5+75 for ; Fri, 18 Feb 2011 07:23:06 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 32AB03A6D27 for ; Fri, 18 Feb 2011 07:23:06 -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 p1IFIBZA078080 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 18 Feb 2011 08:18:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D5E8DB2.6020208@vpnc.org> Date: Fri, 18 Feb 2011 07:18:10 -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: <20110208194502.32308.76943.idtracker@localhost> <4D51A453.1010802@gmail.com> <4D54B383.1090806@vpnc.org> In-Reply-To: <4D54B383.1090806@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-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: Fri, 18 Feb 2011 15:23:07 -0000 On 2/10/11 7:56 PM, Paul Hoffman wrote: > On 2/8/11 12:15 PM, Yaron Sheffer wrote: >> Hi, >> >> this version attempts to address all the open issues that were raised in >> the last few months. In particular, it clarifies the behavior of the IKE >> Message ID during failover while reducing some of the complexity. >> Another significant change is the semantics of the IPsec replay counter >> sync message. >> >> Please review the document. We would like to close the issues in the next >> week or so, and move to WGLC. The currently open issues are here: >> http://tools.ietf.org/wg/ipsecme/trac/query?status=new&status=assigned&status=reopened&component=ipsecha-protocol >> > > +1 to "Please review the document". It would be a bummer to go into WG > LC and then have people find things that take major revision. It's been a week and little review has happened. It feels like we need to go to WG Last Call to get the review, and we should do that soon unless people step up soon. --Paul Hoffman From yaronf.ietf@gmail.com Fri Feb 18 11:59: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 171DF3A6FBE for ; Fri, 18 Feb 2011 11:59:31 -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=[BAYES_00=-2.599, 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 ARVM7g4ksGA7 for ; Fri, 18 Feb 2011 11:59:30 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BF94E3A6FBC for ; Fri, 18 Feb 2011 11:59:29 -0800 (PST) Received: by bwz13 with SMTP id 13so648389bwz.31 for ; Fri, 18 Feb 2011 12:00:03 -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 :subject:content-type:content-transfer-encoding; bh=CqclLDSX/QNRgqSp2KsyR/L4CMDpd+AaOW8yQiojx/4=; b=A+YEe1j3+Roy/nrBz5b0mLTXzdVf6mQtZOIQsciefIhc6knObh2YIS4mLYEM4ZlOBM JDTSsRlPBQKoDXIUc584NbUEf6ZrW/hkvyfNP8jGiUa3RqO7LC/DGclx3M6jrfjnHeod Qc7Z5c/Pv6XHhTHqTgagjmmuiSKybHLNUiMfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=KyqmmYjnQOtzrehtrxA19IkcCSbWKNehgSEcxtKeijcka3RLQr6eFKzRl7NZMZwOP/ z6W56BRjFIuUxr1RRfLgwiMpoR0u/PejE1SzfORcv5ArADXgEpnkF7BmvYcuf0+FJFaE kWgmIyvv26g/3ZnWI/GugVgagySPM6h/HUjgs= Received: by 10.204.123.7 with SMTP id n7mr1067673bkr.33.1298059203477; Fri, 18 Feb 2011 12:00:03 -0800 (PST) Received: from [10.0.0.5] ([109.66.6.124]) by mx.google.com with ESMTPS id x38sm1744845bkj.1.2011.02.18.12.00.01 (version=SSLv3 cipher=OTHER); Fri, 18 Feb 2011 12:00:02 -0800 (PST) Message-ID: <4D5ECFBF.4010600@gmail.com> Date: Fri, 18 Feb 2011 21:59:59 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 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] HA Protocol issue #203 - closed 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, 18 Feb 2011 19:59:31 -0000 This issue (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/203) discusses textual changes required in -02. They are all fixed in -03. Thanks, Yaron From yaronf.ietf@gmail.com Fri Feb 18 12:06: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 307373A6E4D for ; Fri, 18 Feb 2011 12:06:14 -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=[BAYES_00=-2.599, 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 y23KPtrHQcZz for ; Fri, 18 Feb 2011 12:06:13 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 4A5BF3A6DF1 for ; Fri, 18 Feb 2011 12:06:13 -0800 (PST) Received: by fxm15 with SMTP id 15so510910fxm.31 for ; Fri, 18 Feb 2011 12:06:47 -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 :subject:content-type:content-transfer-encoding; bh=FYOsQqYWN1NlqGNk1SUViaKgCz6VreD4ZWZjU3EVyKY=; b=IMnFWg6U1Xif8KQGDOay84WPOwMDzoWq9CTQy2ATpbys6Kx9hwHj45hzEPKbVB1gQ9 ffqX+fImCakE6+ZN8hp+E/2Oi2qdrbrgB1F8+QlL8NAHUa+fVwRh+KEnlU4NXkhsYxj8 p+rAPi0LBjaQwKwOxZkVC4KgBQWTeB/TNbjlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=bM9b3wbV1mzFQn6969LDKkVF8WMWDaTPwGDoWT6Uu+L8WhvA+h8m6JBYaUfnXKImsu pam/CW2/xBv61Z87rSjidsRvc/HmSgRGo82Rxe91xEnx2QwrsvN/p2ur0R/RFPfQbM1L wl2EeDMTFNc+SwBINVrZd8rzVaLIOFGmYyZ48= Received: by 10.223.81.68 with SMTP id w4mr1492924fak.84.1298059606945; Fri, 18 Feb 2011 12:06:46 -0800 (PST) Received: from [10.0.0.5] ([109.66.6.124]) by mx.google.com with ESMTPS id b7sm1279179faa.42.2011.02.18.12.06.45 (version=SSLv3 cipher=OTHER); Fri, 18 Feb 2011 12:06:46 -0800 (PST) Message-ID: <4D5ED152.8060607@gmail.com> Date: Fri, 18 Feb 2011 22:06:42 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 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] HA protocol issue #204 closed 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, 18 Feb 2011 20:06:14 -0000 This issue (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/204) is about the notifications' format (including a conflict with the Critical bit). Fixed in -03. The ESN bit is gone, by the way. Thanks, Yaron From yaronf.ietf@gmail.com Fri Feb 18 12: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 9B5903A6F46 for ; Fri, 18 Feb 2011 12:11:50 -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=[BAYES_00=-2.599, 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 6eD4jXKWPcsX for ; Fri, 18 Feb 2011 12:11:49 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2E4943A6CF4 for ; Fri, 18 Feb 2011 12:11:49 -0800 (PST) Received: by fxm15 with SMTP id 15so516162fxm.31 for ; Fri, 18 Feb 2011 12:12:23 -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 :subject:content-type:content-transfer-encoding; bh=P3LXhWYSfPZJqEs0h4Mq28xA43YJvyGOxW0W3LOjjoE=; b=YuKH653GXVRv1vLTfXYm07MueS359XiTfoLmiz/6mnCnszqDXuyn06ronT1Y0+IysF AiT5SFoXC59LkxpBF1/ilddvgjHaXy/uXIvUOLXeFI68Yb456tFse2+onX/QiDs7wdxk KgurD6T1YaHi8F9WN4jvzkO5kQ9L4ushlZPKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=kf7JvLdxf1JPCw7DxRIDI1aIpRiG+UtNq7CVg0TUxc+gnkgM6IChaTlJBIPOKBEEK1 FFfEGpVOAZJUKcOCHFLDMZzItF1RSW1RiWfFtYliztolzAjvN+WfWZkHrISdGqGC97sc RzxpLFJUHZwTgNj7VQSUZjmeuXdV3/TC2Nbuc= Received: by 10.223.86.135 with SMTP id s7mr1510220fal.70.1298059874384; Fri, 18 Feb 2011 12:11:14 -0800 (PST) Received: from [10.0.0.5] ([109.66.6.124]) by mx.google.com with ESMTPS id y1sm1277764fak.39.2011.02.18.12.11.12 (version=SSLv3 cipher=OTHER); Fri, 18 Feb 2011 12:11:13 -0800 (PST) Message-ID: <4D5ED25E.4000002@gmail.com> Date: Fri, 18 Feb 2011 22:11:10 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 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] HA protocol issue #205 closed 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, 18 Feb 2011 20:11:50 -0000 Issue #205 (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/205) was closed. The nonce is retained in -03, but the failover counter is gone. Replaced by a tighter specification of the allowed counter values, so that legal protocol exchanges never look like replays. From yaronf.ietf@gmail.com Fri Feb 18 12:15: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 4B6543A6F46 for ; Fri, 18 Feb 2011 12:15:41 -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=[BAYES_00=-2.599, 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 PDjE10Ds8Pxd for ; Fri, 18 Feb 2011 12:15:40 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 533C23A6E4D for ; Fri, 18 Feb 2011 12:15:40 -0800 (PST) Received: by bwz13 with SMTP id 13so663762bwz.31 for ; Fri, 18 Feb 2011 12:16:14 -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 :subject:content-type:content-transfer-encoding; bh=aXhnrNAXls+MbSk1zMi+0BWYFO+/4rTNrW5j0Mxq8V4=; b=H+fxVx8//iliumALgNW5uQ6Ijah/BWVIotzV7KV0Y1+t/gKIDRGnL8a0HFc6NEk5Mb mAjZ30K51elPxKZ6HURWCm6pAnz01/xaXuANjWRpiIMhRBwTkiYWMorf7GsSZsRm7Xf0 ZMSnS7TzcZ4B28oEdXHzMC4QkPTDDRPEjWY0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=PBEuv8btFao6BUIB7DdO4NbQF99Ced+GeVBrkqabbFe0qS+yDKibkjQnULquKJn3xH yPAFtN76WC5GI1rHXgOg6T3C/RogMY6CnyHBgRolYtRkiqJ7sEiywMm9zFEeDXgXzeA0 38Y+N4VlUAvXDGvGirIrdbc0AR+f+f3BOAS7M= Received: by 10.204.117.10 with SMTP id o10mr1092605bkq.10.1298060173696; Fri, 18 Feb 2011 12:16:13 -0800 (PST) Received: from [10.0.0.5] ([109.66.6.124]) by mx.google.com with ESMTPS id a17sm1747152bku.23.2011.02.18.12.16.12 (version=SSLv3 cipher=OTHER); Fri, 18 Feb 2011 12:16:13 -0800 (PST) Message-ID: <4D5ED38B.2060304@gmail.com> Date: Fri, 18 Feb 2011 22:16:11 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 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] HA protocol issue #208 closed 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, 18 Feb 2011 20:15:41 -0000 Issue 208 (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/208) was closed. This is fixed in -03. The cluster member increments its own counter unilaterally, and advises the peer on the amount to increment the peer's counter. See Sec. 5.2. From yaronf.ietf@gmail.com Fri Feb 18 12:20: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 A54133A6F9B for ; Fri, 18 Feb 2011 12:20:41 -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=[BAYES_00=-2.599, 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 DyhNxt9WFGEH for ; Fri, 18 Feb 2011 12:20:40 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 460323A6F18 for ; Fri, 18 Feb 2011 12:20:40 -0800 (PST) Received: by bwz13 with SMTP id 13so667724bwz.31 for ; Fri, 18 Feb 2011 12:21:14 -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 :subject:content-type:content-transfer-encoding; bh=p5Xymbw/X+6l7dt0L2ef4sv1Tlwk1y8DaiwbDccJeL8=; b=TdSZQ8zCPbfYYxwv4e8IsqQBwrnc74FghVMFjkZsygplCn7+HsfnHBERYvP8dKde4C PynCOROZB9A6MoGcEbkAH49F66N7M7ji1LL/rcNFkddu3XtCqXOWzi/LkGFR76vnlwaR qZAnqZ8vHjIuHbmpjVIieITyh7XuXiw9bA8So= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=CHg8L0ixjeRHZVhX2H3QDNAoD56HF2Y6K46vYNKyPewwRHbGwCO5SeTYjG74E1edE/ U8B4M+n1c86CO8JQzFmQN99o2k8mDk886T5j/fpVaFAzeoyzlvUZn1QbYZFHJkYhahQE M5g+zBGsxu3xgA1XCpkTdO/HWx2ptJq4RtbAQ= Received: by 10.204.116.79 with SMTP id l15mr1080841bkq.122.1298060472529; Fri, 18 Feb 2011 12:21:12 -0800 (PST) Received: from [10.0.0.5] ([109.66.6.124]) by mx.google.com with ESMTPS id w3sm1756480bkt.5.2011.02.18.12.21.11 (version=SSLv3 cipher=OTHER); Fri, 18 Feb 2011 12:21:11 -0800 (PST) Message-ID: <4D5ED4B6.9070901@gmail.com> Date: Fri, 18 Feb 2011 22:21:10 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 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] HA protocol issue #209 closed 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, 18 Feb 2011 20:20:41 -0000 Issue #209 (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/209) was closed. Fixed in -03 by removal of the problematic text. From yaronf.ietf@gmail.com Fri Feb 18 12:30: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 862AF3A6FD0 for ; Fri, 18 Feb 2011 12:30:21 -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=[BAYES_00=-2.599, 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 UtQKkQQXyzV1 for ; Fri, 18 Feb 2011 12:30:20 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6DB7A3A6DF1 for ; Fri, 18 Feb 2011 12:30:20 -0800 (PST) Received: by fxm15 with SMTP id 15so532047fxm.31 for ; Fri, 18 Feb 2011 12:30:54 -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 :subject:content-type:content-transfer-encoding; bh=GjnGr6mlDY8KfH1YsMi3tDgv04lso+fYE3nwTO7/zSU=; b=XQY7EPWxceZTnqZTdVCGCF1fWNHWY1ITNq6JXSVfTPGBbAu+9OEd0Todb1nV8ZRbjz qIVINbIx3qp63GCyFvCKpK7kKPANQXaAxWDUVCLsQ52+szZ3ORfDSEpM3lDQTIv0150/ l3KQz8hgzK1LWZuaJtJldV6VOWTAFB3h1aSx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=kvHs55+Ewli0LobYU/GXxRl/rcWQaI5YrOUDFQWi/kW4clyS3lBv89bV9yanuvEhr2 841x3Ri0+C/pYJQzfdj9ZhcrO6F4X9ErUfJn45HQFVU9rvTrdR2/N0xfAWv62MceXIrl NiXF+NPAFmryNF2EuW9PjUw60MWFZDnSuOLMo= Received: by 10.223.74.200 with SMTP id v8mr1539853faj.144.1298061053852; Fri, 18 Feb 2011 12:30:53 -0800 (PST) Received: from [10.0.0.5] ([109.66.6.124]) by mx.google.com with ESMTPS id j12sm1291538fax.33.2011.02.18.12.30.51 (version=SSLv3 cipher=OTHER); Fri, 18 Feb 2011 12:30:53 -0800 (PST) Message-ID: <4D5ED6F8.5050405@gmail.com> Date: Fri, 18 Feb 2011 22:30:48 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 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] HA protocol issue #196 closed 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, 18 Feb 2011 20:30:21 -0000 The issue (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/196) was fixed in -03. This situation (multiple failovers) is mentioned in the third bullet of Sec. 5.1, with the newly-active member required to synchronize its state into other cluster members. It is noted that some race situations are still possible in such cases, resulting in a replay-like situation and the IKE SA being torn down. Randomization of counter increment values is a possible remedy here. We believe this situation is rare - and implementation dependent - so this possibility is not mentioned in the text. From ynir@checkpoint.com Mon Feb 21 23:20: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 6D2193A67F2 for ; Mon, 21 Feb 2011 23:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 59Ni5Oz1TLzB for ; Mon, 21 Feb 2011 23:20:44 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0D2A53A6806 for ; Mon, 21 Feb 2011 23:20:43 -0800 (PST) X-CheckPoint: {4D6363F6-20000-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 p1M7LKbB019489 for ; Tue, 22 Feb 2011 09:21:26 +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; Tue, 22 Feb 2011 09:21:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 22 Feb 2011 09:21:21 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Tue, 22 Feb 2011 09:21:21 +0200 Thread-Topic: Putting issue #202 to rest Thread-Index: AcvSYRocioDc1tPCSOy10cR6n0cxdg== Message-ID: <14EE515E-205A-4DEF-9558-08C8A49BE4A3@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: [IPsec] Putting issue #202 to rest 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, 22 Feb 2011 07:20:45 -0000 Hi all. Last week, I submitted version -05 of the failure detection draft. The last= two versions both revolved around rewriting section 9.2 I hope this version is something all of us can live with. If I don't get an= y objections by this week-end, I will close issue #202, and ask Paul & Yaro= n to move the document forward. For your convenience, here's the section: 9.2. QCD Token Transmission A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA. This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a valid QCD token for an IKE SA which is valid on another gateway. This is true whether the attempt to trick the gateway uses the token taker's IP address or a different IP address. IPsec Failure Detection is not applicable to deployments where the QCD secret is shared by multiple gateways and the gateways cannot assess whether the token can be legitimately sent in the clear while another gateway may actually still own the SA's. Load balancer configurations typically fall in this category. In order for a load balancing configuration of IPsec gateways to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members. Because it includes the token taker's IP address in the token generation, the method in Section 5.2 can (under certain conditions) prevent revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address, even in a load- sharing cluster without state synchronization. This method does not prevent revealing the QCD token to an active attacker who is spoofing the token taker's IP address. Such an attacker may attempt to direct messages to a cluster member other than the member responsible for the IKE SA in an attempt to trick that gateway into sending a QCD token for a valid IKE SA. This method should not be used unless the load balancer guarantees that IKE packets from the same source IP address always go to the same cluster member. From kivinen@iki.fi Wed Feb 23 06:43:23 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 37E153A6A17 for ; Wed, 23 Feb 2011 06:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 CRopfYQKdKgF for ; Wed, 23 Feb 2011 06:43:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B68543A6A12 for ; Wed, 23 Feb 2011 06:43:19 -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 p1NEi0hR003005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Feb 2011 16:44:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p1NEi05J001493; Wed, 23 Feb 2011 16:44:00 +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: <19813.7472.338629.315817@fireball.kivinen.iki.fi> Date: Wed, 23 Feb 2011 16:44:00 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 13 min Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 14:43:23 -0000 I wrote draft about the minimal IKEv2 implementation. It does not try to change anything in the RFC5996, it just explains what kind of implementation would be useful in some machine to machine communication scenarios and which would still be complient to the RFC5996 (with an exception of not supporting certificates). The document contains 44 pages, from which the actual protocol description is about 5 pages (IKE_SA_INIT and IKE_AUTH). Half of the document is payload format diagrams copied from RFC5996. This document is meant for people who are not using IPsec for VPNs or similar, but are thinking whether IPsec and IKEv2 could be used in for small devices for machine to machine communications. ---------------------------------------------------------------------- A new version of I-D, draft-kivinen-ipsecme-ikev2-minimal-00.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename: draft-kivinen-ipsecme-ikev2-minimal Revision: 00 Title: Minimal IKEv2 Creation_date: 2011-02-23 WG ID: Independent Submission Number_of_pages: 44 Abstract: This document describes minimal version of the Internet Key Exchange version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation, and also describes various optimizations which can be done. The protocol described here is compliant with full IKEv2 with exception that this document only describes shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication). This document does not update or modify RFC 5996, but provides more compact description of the minimal version of the protocol. If this document and RFC 5996 conflicts then RFC 5996 is the authoritative description. -- kivinen@iki.fi From smoonen@us.ibm.com Wed Feb 23 08:35: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 7637F3A6892; Wed, 23 Feb 2011 08:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[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 V95QSgUoAVVS; Wed, 23 Feb 2011 08:35:01 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id CF6D73A691A; Wed, 23 Feb 2011 08:35:00 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1NGBBW4025675; Wed, 23 Feb 2011 11:11:11 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1NGZcKA188970; Wed, 23 Feb 2011 11:35:38 -0500 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 p1NGZbem032071; Wed, 23 Feb 2011 09:35:37 -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 p1NGZbXJ032058; Wed, 23 Feb 2011 09:35:37 -0700 In-Reply-To: <14EE515E-205A-4DEF-9558-08C8A49BE4A3@checkpoint.com> References: <14EE515E-205A-4DEF-9558-08C8A49BE4A3@checkpoint.com> X-KeepSent: 848F7307:2A6AF8BE-85257840:005A1862; 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: Wed, 23 Feb 2011 11:28:13 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 02/23/2011 09:35:36 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF2D3DFC99EF28f9e8a93df938690918c0ABBF2D3DFC99EF2" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Putting issue #202 to rest 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, 23 Feb 2011 16:35:04 -0000 --0__=0ABBF2D3DFC99EF28f9e8a93df938690918c0ABBF2D3DFC99EF2 Content-type: multipart/alternative; Boundary="1__=0ABBF2D3DFC99EF28f9e8a93df938690918c0ABBF2D3DFC99EF2" --1__=0ABBF2D3DFC99EF28f9e8a93df938690918c0ABBF2D3DFC99EF2 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Yoav, thanks. I'm ok with this text. However, because of Tero's observations about the man-in-the-middle wording, we might want to impr= ove the phrase "revealing the QCD token to an active attacker who is spoofi= ng" to read "sending the QCD token due to an active attacker who is spoofin= g." Note that there are two sentences with similar phrasing, but we only ne= ed to change the latter. 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: 02/22/2011 02:21 AM Subject: [IPsec] Putting issue #202 to rest Sent by: ipsec-bounces@ietf.org Hi all. Last week, I submitted version -05 of the failure detection draft. The = last two versions both revolved around rewriting section 9.2 I hope this version is something all of us can live with. If I don't ge= t any objections by this week-end, I will close issue #202, and ask Paul = & Yaron to move the document forward. For your convenience, here's the section: 9.2. QCD Token Transmission A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA. This requirement is obvious and easy in the case of a single gateway= . However, some implementations use a load balancer to divide the load= between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a valid QCD token for an IKE SA which is valid on another gateway. This is true= whether the attempt to trick the gateway uses the token taker's IP address or a different IP address. IPsec Failure Detection is not applicable to deployments where the QCD secret is shared by multiple gateways and the gateways cannot assess whether the token can be legitimately sent in the clear while= another gateway may actually still own the SA's. Load balancer configurations typically fall in this category. In order for a load= balancing configuration of IPsec gateways to support this specification, all members MUST be able to tell whether a particular= IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members.= Because it includes the token taker's IP address in the token generation, the method in Section 5.2 can (under certain conditions)= prevent revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address, even in a load- sharing cluster without state synchronization. This method does not= prevent revealing the QCD token to an active attacker who is spoofin= g the token taker's IP address. Such an attacker may attempt to direc= t messages to a cluster member other than the member responsible for the IKE SA in an attempt to trick that gateway into sending a QCD token for a valid IKE SA. This method should not be used unless the= load balancer guarantees that IKE packets from the same source IP address always go to the same cluster member. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBF2D3DFC99EF28f9e8a93df938690918c0ABBF2D3DFC99EF2 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Yoav, thanks. I'm ok with this text. However, because of Tero's obse= rvations about the man-in-the-middle wording, we might want to improve = the phrase "revealing the QCD token to an active attacker who is s= poofing" to read "sending the QCD token due to an active atta= cker who is spoofing."

Note that there are two sentences with similar phrasing, but we only ne= ed to change the latter.


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

3D"InactiveYoav Nir ---02/22/20= 11 02:21:52 AM---Hi all. Last week, I submitted version -05 of the fail= ure detection draft. The last two versions bot

From: Yoav N= ir <ynir@checkpoint.com>
To: "ip= sec@ietf.org" <ipsec@ietf.org>
Date: 02/22/= 2011 02:21 AM
Subject: [IP= sec] Putting issue #202 to rest
Sent by: ips= ec-bounces@ietf.org




Hi all.

Last week, I submitted version -05 of the failure detection draft. The = last two versions both revolved around rewriting section 9.2

I hope this version is something all of us can live with. If I don't ge= t any objections by this week-end, I will close issue #202, and ask Pau= l & Yaron to move the document forward.  For your convenience,= here's the section:

9.2.  QCD Token Transmission


  A token maker MUST NOT send a valid QCD token in an unprotected=
  message for an existing IKE SA.

  This requirement is obvious and easy in the case of a single ga= teway.
  However, some implementations use a load balancer to divide the= load
  between several physical gateways.  It MUST NOT be possibl= e even in
  such a configuration to trick one gateway into sending a valid = QCD
  token for an IKE SA which is valid on another gateway.  Th= is is true
  whether the attempt to trick the gateway uses the token taker's= IP
  address or a different IP address.

  IPsec Failure Detection is not applicable to deployments where = the
  QCD secret is shared by multiple gateways and the gateways cann= ot
  assess whether the token can be legitimately sent in the clear = while
  another gateway may actually still own the SA's.  Load bal= ancer
  configurations typically fall in this category.  In order = for a load
  balancing configuration of IPsec gateways to support this
  specification, all members MUST be able to tell whether a parti= cular
  IKE SA is active anywhere in the cluster.  One way to do i= t is to
  synchronize a list of active IKE SPIs among all the cluster mem= bers.

  Because it includes the token taker's IP address in the token   generation, the method in Section 5.2 can (under certain condit= ions)
  prevent revealing the QCD token for an existing pair of IKE SPI= s to
  an attacker who is using a different IP address, even in a load= -
  sharing cluster without state synchronization.  This metho= d does not
  prevent revealing the QCD token to an active attacker who is sp= oofing
  the token taker's IP address.  Such an attacker may attemp= t to direct
  messages to a cluster member other than the member responsible = for
  the IKE SA in an attempt to trick that gateway into sending a Q= CD
  token for a valid IKE SA.  This method should not be used = unless the
  load balancer guarantees that IKE packets from the same source = IP
  address always go to the same cluster member.


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

= --1__=0ABBF2D3DFC99EF28f9e8a93df938690918c0ABBF2D3DFC99EF2-- --0__=0ABBF2D3DFC99EF28f9e8a93df938690918c0ABBF2D3DFC99EF2 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF2D3DFC99EF28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF2D3DFC99EF28f9e8a93df938690918c0ABBF2D3DFC99EF2-- From paul.hoffman@vpnc.org Wed Feb 23 08:38: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 5679D3A68F2 for ; Wed, 23 Feb 2011 08:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.422 X-Spam-Level: X-Spam-Status: No, score=-101.422 tagged_above=-999 required=5 tests=[AWL=0.624, 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 U3u9MXERU6f6 for ; Wed, 23 Feb 2011 08:38:13 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A01B53A6892 for ; Wed, 23 Feb 2011 08:38: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 p1NGd0CD013555 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 23 Feb 2011 09:39:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D653825.6090002@vpnc.org> Date: Wed, 23 Feb 2011 08:39:01 -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: <19813.7472.338629.315817@fireball.kivinen.iki.fi> In-Reply-To: <19813.7472.338629.315817@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 16:38:14 -0000 Thanks, Tero. I doubt that this will become a WG item because we are hoping to shut the WG down after our two current documents are finished. However, I would encourage people on the list to review the document, particularly for things that Tero missed that *need* to be in a minimal implementation. I'm hoping after a rev or two that Tero will publish this as an RFC. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Feb 23 08:59: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 8CEC43A68F2 for ; Wed, 23 Feb 2011 08:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.696 X-Spam-Level: X-Spam-Status: No, score=-100.696 tagged_above=-999 required=5 tests=[AWL=-0.139, 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 LVLkkzcE0S+Y for ; Wed, 23 Feb 2011 08:59:29 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E22B83A67A1 for ; Wed, 23 Feb 2011 08:59:28 -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 p1NH0FuR014374 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 23 Feb 2011 10:00:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D653D20.9060007@vpnc.org> Date: Wed, 23 Feb 2011 09:00: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: <14EE515E-205A-4DEF-9558-08C8A49BE4A3@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Putting issue #202 to rest 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, 23 Feb 2011 16:59:29 -0000 I have already sent the new draft to our AD for consideration to bring to IETF Last Call. Changes can certainly be made after IETF Last Call, and this discussion seems worthwhile there. --Paul Hoffman, Director --VPN Consortium From iesg-secretary@ietf.org Thu Feb 24 12:03: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 E17BB3A6832; Thu, 24 Feb 2011 12:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 BhUO1nEZo+OE; Thu, 24 Feb 2011 12:03:20 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0148B3A67D4; Thu, 24 Feb 2011 12:03:20 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110224200320.26184.57475.idtracker@localhost> Date: Thu, 24 Feb 2011 12:03:20 -0800 Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (A Quick Crash Detection Method for IKE) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 20:03:21 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'A Quick Crash Detection Method for IKE' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-failure-detection/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-failure-detection/ No IPR declarations have been submitted directly on this I-D.