On Wed, Nov 26, 2014 at 08:10:35PM +0000, Graham Bartlett (grbartle) wrote: > Great point. Puzzles a good tool that will be needed if/when ddos becomes > a serious issue. (I can't think of a silver bullet which will solve this)
For VPN SGs using puzzles all the time would be fine, but for VPN clients it'd be very rude to use them when acting as the responder! The protocol may be symmetric, but some uses aren't. VPN clients probably don't talk to more than one SG at a time, so why should they need puzzles at all? For single-user VPN clients there's not much of a DDoS problem. Even for BITW uses... For end-to-end IPsec using complex puzzles all the time would probably not be useful at all, but using them as load goes up would be very appropriate. Responder load seems like a variable that always works for deciding when to use puzzles and how complex they should be. VPN clients generally will never have too much IKE load, while SGs make tempting DDoS targets, therefore SGs could definitely use puzzles when under attack. Another variable worth using for determining puzzle complexity is the responder's estimated cost of holding the half-open IK_SA and completing the exchange. For a protocol where the initiator can demonstrate having recently been a productive peer there may be no need to make the initiator spend a lot of time on puzzles -- no need to punish the innocent parties, when you know who they are (but innocence is difficult to determine). > They should also not be mandatory (with the option to be configurable as > per cookie notifications) as I would assume some hosts will never be able > to support these.. Yes, but I'd rather we have a general recommendation with as simple a configuration knob as possible and with a sensible default setting that most will never need to change. IKE load seems like the most sensible variable to use in deciding when to use puzzles and how hard they should be. Specify the feature (puzzles) and provide general guidance as to when to use it and how hard to make it on the initiator. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
