Re: session resumption, I would like to propose the following text:
6.1. Session Resumption
When the Responder is under attack, it MAY choose to prefer previously
authenticated peers who present a session resumption [RFC 5723] ticket.
The Responder MAY require such Initiators to include a return
routability ticket in the IKE_SESSION_RESUME message, as allowed by RFC
5723, Sec. 4.3.2. Note that the Responder SHOULD cache tickets for a
short time to reject reused tickets (Sec. 4.3.1), and therefore there
should be no issue of half-open SAs resulting from replayed
IKE_SESSION_RESUME messages.
Thanks,
Yaron
On 02/09/2015 04:52 PM, Yoav Nir wrote:
On Feb 9, 2015, at 4:03 AM, Paul Wouters <[email protected]> wrote:
On Sun, 8 Feb 2015, Yaron Sheffer wrote:
I think we've come a full circle. We now have a proposal that makes
proof-of-work more deterministic for each type of client (which I find very
useful). But the weaker clients will always lose, no matter what POW solution
we choose. This has been a problem with this proposal from day one and it's a
limitation that we as a group need to decide whether to accept or not.
I'm not yet convinced this proposal will provide a working solution to
the DDOS problem.
Hi, Paul
“solution” is hard. Whatever we do, an attacker with unlimited resources can
throw more at us.
We could block all regular initiations under load, allowing only RFC 5723
resumptions. But this allows an attacker to force us into this mode and
effectively deny service to all initiators that don’t have a saved session.
So instead we can allow resumptions and also make it more costly for the
attacker to mount the attack on regular initiations. Even an easy puzzle, one
that my 1.2 GHz single-core ARMv5 with C code can solve in a second is much
harder than just the return routability that COOKIE provides. The draft has
text about how to make these puzzles a weapon of last resort, so legitimate
users hardly ever need to solve them, but even setting the puzzle difficulty to
something a strong desktop can do 20 times a second, it’s still better than the
two other alternatives: allow the strong desktop to create 1000 half-open SAs
in a second, or entirely block the subnet from which the desktop seems to come.
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
