On Sep 25, 2014, at 2:27 PM, Tero Kivinen <[email protected]> wrote: > Michael Richardson writes: >> Yoav Nir <[email protected]> wrote: >>> One proposal that I kind of liked (and I’m sorry I’ve forgotten who >>> suggested it) was to relegate the puzzle to a second line of defense, >>> through the use of some kind of anti-dos ticket. The ticket would be a >>> bearer token (perhaps an encrypted timestamp) that would allow the >>> bearer to get by with a much easier version of the puzzle. The >> >> Would this ticket be provided in a Notify, after AUTHentication, in a >> previous PARENT-SA? > > Wouldn't it be better to use IKEv2 session resumption (RFC 5723) for > those clients coming back. > > I.e if you resume old existing session then you do not need to do > puzzle... And after the resume, the ticket is usually changed again, > so the ticket would always be fresh.
That’s possible. But session tickets are different from these tickets in two ways: 1. Session tickets are time-limited with a rather short validity period. If policy requires checking the certificate / password every two hours, then the ticket cannot be valid for more than that. 2. Session tickets must not be replayed, so the gateway has to use some very strict anti-replay mechanisms. The proposed tickets can be valid for a long time, and while replay prevention is desired, it doesn’t need to be very strict. This laxness has operational benefits. It’s easier to implement in a cluster of gateways, and a ticket will be valid even for a user that hasn’t connected in a while. This makes sense because the prize from a replayed RFC 5723 ticket is great - a valid, authenticated session. OTOH managing to replay this new kind of ticket only gets you a half-open SA without bothering to solve a puzzle. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
