Subject: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193

From: Frederic Detienne <[email-masked]>
Date: Fri, 15 Oct 2010 11:53:39 +0200

Hi Yaron,

In response to issue 193. For reference:

--8<--
Section 9.3: this entire discussion is probably redundant, because when a node fails in the LS cluster, you switch to another node. Implementing QCD on top of this is probably an overkill. If we remove this section, we can get rid of sec. 5.2 as well, and we can focus on a single recommended way to generate the token, which would make analysis that much easier.
--8<--

9.3 has been moved to 10.4 under security consideration. I will refer to 10.4 instead of 9.3 from now on.

The token generation method highlighted in 5.1 presents a security risk highlighted in section 10.4.

We can not get rid of 5.2 nor 10.4, however we could make it clearer that 5.2 is the recommended token generation method when the risk highlighted in10.4 is present.

Regards,

	fred

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 Oct 2010 14:57:00 +0200

Hi Frederic,

I understand the scenario now and I agree that a solution is needed. But 
I have two issues, one general and one specific:

- Even though there are no interoperability implications, I think we 
should specify the token format. This will prevent people from making 
some security-critical design mistakes. In other words, we should have 
*one* token generation method.

- The proposed method uses the taker's IP address, making some 
assumptions on the load balancer's behavior. But what if the load 
balancer behaves a bit differently, e.g. by including the source port in 
the decision function? Such a system will still have the vulnerability. 
What if we choose instead to include the *maker* identity (a sequential 
member number, or a private IP, or even a MAC address)? This would 
prevent another member from re-generating the same token for an 
attacker, and as a side benefit, will not require token changes when the 
client is roaming.

Thanks,
	Yaron

On 15/10/10 11:53, Frederic Detienne wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 Oct 2010 15:41:31 +0200

> *one* token generation method.

Since there are no interoperability implications, I thing we should not specify the format, merely suggest it. Same as we suggest a Cookie format in RFC 5996:
                      The exact
   algorithms and syntax used to generate cookies do not affect
   interoperability and hence are not specified here.  The following is
   an example of how an endpoint could use cookies to implement limited
   DoS protection.

Also, if different methods match different scenarios, I don't think we should have any problem with specifying^H^H^H^H^H^H^H^H^H^H suggesting *two* methods. I would not want to implement the method in section 5.2 just because somebody has some issues with a load balancer.

> attacker, and as a side benefit, will not require token changes when the 

Yes, but this will interact badly with clusters. We actually do want two cluster members to return the same tokens for the same IKE SPIs. If they have their states synched often, then it's no problem, because they both know which IKE SAs exist, and which do not. If they don't have their states synched and they are hot-standby, we also don't have a problem, because a fail-over is like a reboot (but much faster), and you can't get a response from the non-active member. The only problem scenario is when you have load sharing and no synchronized state, and no control over the load balancer (otherwise, I would tell it to balance by the initiator's IKE SPI).  So if one member fails, you can't get the others to offer valid QCD tokens, and the IKE SAs have to take the long route to recovery. With the method in 5.2, the other members (which don't have state) can still create valid QCD tokens, to get all those clients that connected to the down gateway to begin IKE again. 

> Scanned by Check Point Total Security Gateway.

---

From: Frederic Detienne <[email-masked]>
Date: Sun, 17 Oct 2010 21:29:14 +0200

This type of debate happened before and once again, it is critical to design a secure protocol rather than a protocol that can/may be implemented securely.

The rejoinder is to
 - offer recommended cookie computation methods
 - highlight the risks of each method and the risks of doing something else

This way, those who follow the spec can ascertain their computation method is secure and has a well defined domain of applicability.

I feel the draft is headed in the right direction.

If we take out computation methods, we probably ought to restrict the domain of applicability of the specification and/or spend more time highlighting the risk of do-it-yourself cookie methods. Neither option looks attractive.

Notice the problem of address-less cookie is not limited to load balanced clusters. If the attacker can somehow target a device owning the QCD cookie-generating-key but not owning the SA, this attacker may gain access to the QCD token for a given SPI. This applies _for instance_ to HSRP pairs if the real addresses of the devices are accessible by the attacker and if the standby device accepts connections. This is just an example but it is likely to affect many implementations in practice.

The address-less method will likely require more severe warnings in order to restrict or constraint its domain of applicability.

regards,

	fred

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Oct 2010 10:09:45 +0200

Hi all

I have started this thread about this issue a week ago, and so far the only responses we have had are from Yaron and Frederic. I would like to hear some more, because this issue is very central.

Here's a summary of my take on this issue.

The draft does not mandate any particular method of token generation (in this, we follow the example of the stateless cookie in RFC 5996). It does, however, suggest two such methods, both of which are somewhat similar to the cookie generation method suggested in RFC 5996:

1. The method in section 5.1 involves hashing a secret with the IKE SPIs
2. The method in section 5.2 involves hashing a secret with the IKE SPIs and the token taker's IP address.

The big disadvantage of the method in 5.2 is that whenever the token taker's IP address changes (as is common for roaming clients) the Token has to be replaced. The advantage is that in a certain configuration (details below) it prevents a token discovery attack. This attack involves tricking one gateway to send a clear QCD token for an IKE SA owned by another gateway. If a cluster is located behind a load balancer, at attacker can attempt to send fake IKE messages from various IP addresses, until those requests reach the "wrong" gateway, which will generate a QCD token that can be used to cause the original token taker to disconnect.

Details of this scenario: For this attack to take place, we need all of the following:
 - A group of gateways, all sharing the same QCD token secret.
 - A disjoint IKE SA database, meaning that IKE SAs are not synchronized. One member in this cluster cannot know if a particular IKE SA exists on another member.
 - The ability of an attacker to direct requests to different members (either by varying its IP address or by directly addressing the member), and a willingness of all members to reply with a QCD token.

We are not saying that having such no-sync clusters is a good idea. In fact, it may be a good idea to recommend against them in the ipsecha document. But they do exist. I have no problem recommending that implementations that don't have such concerns just go ahead and implement the method in 5.1, but since these things do exist, I think it's OK to recommend the method in 5.2 for these configurations.  Frederic is apparently with me on this, which is good. Yaron has some doubts, though, and we'd really like to hear what other people think.

Yoav

---

From: David Wierbowski <[email-masked]>
Date: Wed, 20 Oct 2010 09:05:27 -0400

I think it is fine to not mandate a particular method of token generation.
I think it is sufficient to provide two recommendations with an applicable
explanation of pros and cons.  I do not think this will lead implementers
to  make security-critical design mistakes.  Most implementers can read an
RFC and understand the issues.  When in doubt they post a question here.

Dave Wierbowski

From:       Yoav Nir <[email-masked]>
To:         IPsecme WG <[email-masked]>
Date:       10/20/2010 04:10 AM
Subject:    Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue
            193
Sent by:    [email-masked]

Hi all

I have started this thread about this issue a week ago, and so far the only
responses we have had are from Yaron and Frederic. I would like to hear
some more, because this issue is very central.

The draft does not mandate any particular method of token generation (in
this, we follow the example of the stateless cookie in RFC 5996). It does,
however, suggest two such methods, both of which are somewhat similar to
the cookie generation method suggested in RFC 5996:

1. The method in section 5.1 involves hashing a secret with the IKE SPIs
2. The method in section 5.2 involves hashing a secret with the IKE SPIs
and the token taker's IP address.

The big disadvantage of the method in 5.2 is that whenever the token
taker's IP address changes (as is common for roaming clients) the Token has
to be replaced. The advantage is that in a certain configuration (details
below) it prevents a token discovery attack. This attack involves tricking
one gateway to send a clear QCD token for an IKE SA owned by another
gateway. If a cluster is located behind a load balancer, at attacker can
attempt to send fake IKE messages from various IP addresses, until those
requests reach the "wrong" gateway, which will generate a QCD token that
can be used to cause the original token taker to disconnect.

Details of this scenario: For this attack to take place, we need all of the
following:
 - A group of gateways, all sharing the same QCD token secret.
 - A disjoint IKE SA database, meaning that IKE SAs are not synchronized.
One member in this cluster cannot know if a particular IKE SA exists on
another member.
 - The ability of an attacker to direct requests to different members
(either by varying its IP address or by directly addressing the member),
and a willingness of all members to reply with a QCD token.

We are not saying that having such no-sync clusters is a good idea. In
fact, it may be a good idea to recommend against them in the ipsecha
document. But they do exist. I have no problem recommending that
implementations that don't have such concerns just go ahead and implement
the method in 5.1, but since these things do exist, I think it's OK to
recommend the method in 5.2 for these configurations.  Frederic is
apparently with me on this, which is good. Yaron has some doubts, though,
and we'd really like to hear what other people think.

Yoav

On Oct 17, 2010, at 9:29 PM, Frederic Detienne wrote:

>
> This type of debate happened before and once again, it is critical to
design a secure protocol rather than a protocol that can/may be implemented
securely.
> This way, those who follow the spec can ascertain their computation
method is secure and has a well defined domain of applicability.
> If we take out computation methods, we probably ought to restrict the
domain of applicability of the specification and/or spend more time
highlighting the risk of do-it-yourself cookie methods. Neither option
looks attractive.
>
> Notice the problem of address-less cookie is not limited to load balanced
clusters. If the attacker can somehow target a device owning the QCD
cookie-generating-key but not owning the SA, this attacker may gain access
to the QCD token for a given SPI. This applies _for instance_ to HSRP pairs
if the real addresses of the devices are accessible by the attacker and if
the standby device accepts connections. This is just an example but it is
likely to affect many implementations in practice.
>
> The address-less method will likely require more severe warnings in order
to restrict or constraint its domain of applicability.
>> Since there are no interoperability implications, I thing we should not
specify the format, merely suggest it. Same as we suggest a Cookie format
in RFC 5996:
>> Also, if different methods match different scenarios, I don't think we
should have any problem with specifying^H^H^H^H^H^H^H^H^H^H suggesting
*two* methods. I would not want to implement the method in section 5.2 just
because somebody has some issues with a load balancer.

>> Yes, but this will interact badly with clusters. We actually do want two
cluster members to return the same tokens for the same IKE SPIs. If they
have their states synched often, then it's no problem, because they both
know which IKE SAs exist, and which do not. If they don't have their states
synched and they are hot-standby, we also don't have a problem, because a
fail-over is like a reboot (but much faster), and you can't get a response
from the non-active member. The only problem scenario is when you have load
sharing and no synchronized state, and no control over the load balancer
(otherwise, I would tell it to balance by the initiator's IKE SPI).  So if
one member fails, you can't get the others to offer valid QCD tokens, and
the IKE SAs have to take the long route to recovery. With the method in
5.2, the other members (which don't have state) can still create valid QCD
tokens, to get all those clients that connected to the down gateway to
begin IKE again.
>>>> Section 9.3: this entire discussion is probably redundant, because
when a node fails in the LS cluster, you switch to another node.
Implementing QCD on top of this is probably an overkill. If we remove this
section, we can get rid of sec. 5.2 as well, and we can focus on a single
recommended way to generate the token, which would make analysis that much
easier.
>>>> We can not get rid of 5.2 nor 10.4, however we could make it clearer
that 5.2 is the recommended token generation method when the risk
highlighted in10.4 is present.