Bora Akyol wrote: ... >>>Finally, as is widely discussed, IKEv1 is not the most >>robust protocol >>>as far as responsiveness to DOS attacks. By requiring these >>nodes to do >>>IKE, I think we would opening ourselves up for more problems. >>> >>>Regards, >>> >>>Bora >> >>I don't appreciate enough of the details between IKEv1 and IKEv2 to >>understand whether that would solve the problem. >> >>I would presume that IKE would be rate-limited, i.e., the >>same way SYN >>processing is for TCP, to protect new association requests from >>assaulting existing associations. Is that the issue with DOS >>for IKEv1, >>or is there something more specific? >> >>Joe > > IKEv1 creates state for each new connection on the first packet, so does > IKEv2 > unless the cookie option is used which is left as a non-mandatory > feature > in the draft only to be activated when the system detects its under > attack. > > Due to this, I think moving the security problem down to IKE does not > solve it, it just shifts it. > > Thanks for your comments, > > Bora Hi, Bora, The revision to the draft will address this in further detail. Some initial thoughts: 1) ANONike costs more in open SPIs and messages, but a lot less in certificate validation costs vs. using a known CA (though as before the difference - if any - between ANONike and preshared fixed keys should be examined further) 2) I heartily agree that this shifts the problem, IMO to a place that ought to be optimized to handle it. I.e., moving it to IKE means we solve it once, at least for attacks from off-path spoofers 3) if you have an on-path attack, you really just have load - notably since I'm assuming you turned on ANONsec because you're running a publicly available service shedding load for public services is also a well-known issue, and certainly needs to be considered. ANONsec helps avoid the off-path attacks, not the on-path from parties willing to setup full associations, either at the IPsec or TCP layers Joe
Attachment:
signature.asc
Description: OpenPGP digital signature