Re: [IPsec] Failure detection proposals

[David Wierbowski <[e-mail]>]

I agree with Scott and I am also willing to participate in discussion of
the alternatives.

Dave Wierbowski





From:       Scott C Moonen/Raleigh/IBM@IBMUS
To:         Yaron Sheffer <[e-mail]>
Cc:         IPsecme WG <[e-mail]>, [e-mail]
Date:       08/05/2010 09:33 AM
Subject:    Re: [IPsec] Failure detection proposals
Sent by:    [e-mail]



I think this is an important problem to solve and I'm willing to
participate in discussion of the alternatives,

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

(Embedded image moved to file: pic03142.gif)Inactive hide details for Yaron
Sheffer ---08/04/2010 04:48:45 PM---In the Maastricht meeting there was
just a tiny bit of inteYaron Sheffer ---08/04/2010 04:48:45 PM---In the
Maastricht meeting there was just a tiny bit of interest in the failure
detection idea (remi

From: Yaron Sheffer <[e-mail]>
To: IPsecme WG <[e-mail]>
Date: 08/04/2010 04:48 PM
Subject: [IPsec] Failure detection proposals
Sent by: [e-mail]



In the Maastricht meeting there was just a tiny bit of interest in the
failure detection idea (reminder: the goal is to ensure that one peer
discovers that the other IKE peer has restarted, within a short time
duration, milliseconds instead of minutes). But we didn't see enough
interest to justify having this as a WG item. So, one last time: if you
think this is a worthwhile idea, regardless of the proposals on the
table, please say so publicly. If you speak up, we will expect you to
contribute to the selection of the preferred document.

If this is of no interest, fine. But if it is an important problem to
solve and we don't take it on, we could end up with competing non-WG
proposals. Which would be far from ideal.

Thanks,
Yaron

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Paul Hoffman
Sent: Wednesday, July 07, 2010 8:03 PM
To: IPsecme WG
Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals

[[ This topic generated a fair amount of discussion in the past; are
folks still interested? ]]

Greetings again. The WG has one item on our charter that we have barely
discussed, namely failure detection. The charter item says that the work
item is:

>- A standards-track IKEv2 extension that allows an IKE peer to quickly and
securely detect that its opposite peer, while currently reachable, has lost
its IKEv2/IPsec state. Changes to how the peers recover from this situation
are beyond the scope of this work item, as is improving the detection of an
unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and
draft-detienne-ikev2-recovery-03 can be used as starting points.

I gave a brief presentation on failure detection at the last IETF
meeting in Anaheim. The slides are at
<http://www.ietf.org/proceedings/77/slides/ipsecme-4.pdf>, and the
following is directly derived from them.

The basic problem being covered by the new extension is:
-  Alice and Bob have SAs up and ESP traffic is flowing, but then Bob
crashes
-  Alice keeps sending ESP to Bob
-  When Bob finally comes back up, he replies to Alice's ESP with
INVALID_SPI notifications
-  Alice starts sending IKE liveness checks until she is "sure" that the
INVALID_SPI responses are not a DoS attack; this could be "several minutes"
-  Then Alice rekeys

Some other problem cases include:
-  Bob has two gateways in some failover architecture. One gateway goes
down, the other gateway detects this and wants to tell Alice to rekey
-  Bob has a bunch of gateways in some load-balancing or cluster
architecture. One gateway is taken down on purpose, and the system wants
to tell Alice to rekey
-  Protocol robustness:  Bob's gateway loses the SA without going down

Our primary goal is that, as soon as Bob starts sending INVALID_SPI
responses to Alice's ESP traffic, Bob and Alice should be able to
quickly determine that this is not an attack and therefore they probably
want to rekey right away. Note that if Bob and Alice are also using
session resumption, they can use that instead of rekeying; however, in
the discussion here, we always use "rekey" to mean "rekey or, if
appropriate, resume". The proposed extension does not include the actual
rekeying, just the context for them to do it now.

The WG has seen two proposed solutions, QCD and SIR. The following are
brief summaries of the two proposals.

In QCD (<http://tools.ietf.org/html/draft-nir-ike-qcd>), Bob gives Alice
a secret token in the AUTH exchange, and then puts the token in his
INVALID_SPI response as a way to say "this SPI is gone". Bob must
remember his tokens across reboots, or derive tokens from a master token
that he memorizes across reboots, and Alice must remember the token (or
a hash of it) for each SA.

In SIR
(<http://tools.ietf.org/id/draft-detienne-ikev2-recovery-03.txt>), Alice
sends a new Check_SPI query with a stateless cookie, essentially asking
"do you really not know about this
SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing
is stored on either side, so a man-in-the-middle can attack this to
cause an unnecessary rekey just as they can normal IKE.

The first task for the WG is to decide which of these two quite
different approaches to take. After we have done that, we can then hone
the chosen proposal. During earlier discussion of the proposals, the
following criteria were mentioned as ones that the WG should consider
when thinking about the approaches:

-  Support for different scenarios (load balancers, active clusters,
failover)
-  Security from man-in-the-middle DoS attacks
-  Resources used
-  Intellectual property rights

So: please start discussing the two proposals with respect to these
criteria or other criteria that are important to you. In a few weeks
(hopefully well before the Maastricht meeting), I make a call for
consensus and see where it leads us.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec