Subject: [IPsec] Fwd: Failure Detection - issue #202

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Feb 2011 23:29:45 +0200

Adding the IPsec list.

Begin forwarded message:

From: Frederic Detienne <[email-masked]<mailto:[email-masked]>>
Date: February 1, 2011 9:37:33 PM GMT+02:00
To: Paul Hoffman <[email-masked]<mailto:[email-masked]>>
Cc: Yoav Nir <[email-masked]<mailto:[email-masked]>>, Pratima Sethi <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

---

From: David Wierbowski <[email-masked]>
Date: Wed, 2 Feb 2011 09:40:04 -0500

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 <[email-masked]>
To:	"[email-masked]" <[email-masked]>
Date:	02/01/2011 04:30 PM
Subject:	[IPsec] Fwd:  Failure Detection - issue #202
Sent by:	[email-masked]

Adding the IPsec list.

Begin forwarded message:

      From: Frederic Detienne <[email-masked]>
      Date: February 1, 2011 9:37:33 PM GMT+02:00
      To: Paul Hoffman <[email-masked]>
      Cc: Yoav Nir <[email-masked]>, Pratima Sethi <[email-masked]>,
      Yaron Sheffer <[email-masked]>
      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

            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

                  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:

                    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:

                    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

                  [email-masked]

[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 4 Feb 2011 11:21:36 -0500

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

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:	David Wierbowski/Endicott/IBM@IBMUS
To:	Yoav Nir <[email-masked]>
Cc:	"[email-masked]" <[email-masked]>, [email-masked]
Date:	02/02/2011 09:40 AM
Subject:	Re: [IPsec] Fwd:  Failure Detection - issue #202
Sent by:	[email-masked]

Dave Wierbowski

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

Adding the IPsec list.

Begin forwarded message:

      Hi Paul, Yoav,

      The statement:

      -8<---

      -8<---

      -8<---

      thanks and regards,

      Frederic

            --Paul Hoffman

                  OLD:

                  NEW:

                  Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 07 Feb 2011 12:20:22 -0800

Any other comments on this issue and the proposals for wording?

--Paul Hoffman, Director
--VPN Consortium

---

From: Frederic Detienne <[email-masked]>
Date: Tue, 8 Feb 2011 18:28:30 +0100

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.
> 
> 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.
> 
> 
> 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."
>