Subject: [IPsec] Failure Detection - issue #202

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Feb 2011 17:05:26 +0200

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: Paul Hoffman <[email-masked]>
Date: Thu, 10 Feb 2011 19:25:06 -0800

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

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: Yoav Nir <[email-masked]>
Date: Fri, 11 Feb 2011 11:56:03 +0200

Done.

On Feb 11, 2011, at 11:54 AM, IETF I-D Submission Tool wrote:

> 
> A new version of I-D, draft-ietf-ipsecme-failure-detection-04.txt has been successfully submitted by Yoav Nir and posted to the IETF repository.
> 
> 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
> 
> Abstract:
> 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.
> 
> 
> 
> The IETF Secretariat.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 11 Feb 2011 13:37:59 +0200

> 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.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Fri, 11 Feb 2011 10:08:40 -0500

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 <[email-masked]>
To:	Paul Hoffman <[email-masked]>
Cc:	[email-masked]
Date:	02/11/2011 06:38 AM
Subject:	Re: [IPsec] Failure Detection - issue #202
Sent by:	[email-masked]

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.
--
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Feb 2011 08:20:35 -0800

On 2/11/11 7:08 AM, David Wierbowski wrote:
> 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
> 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: Tero Kivinen <[email-masked]>
Date: Mon, 14 Feb 2011 15:14:17 +0200

Paul Hoffman writes:
> > 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

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.

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

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

> 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. 
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 14 Feb 2011 12:07:42 -0500

I'm ok with Dave's proposed text, with or without Tero's proposed changes.

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.

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

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

Date:	02/14/2011 08:14 AM

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 15 Feb 2011 15:48:11 +0200

> revelation if he is not in the middle, but it's still improper to reveal

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.
-- 
[email-masked]