Valery Smyslov writes: > Well, I don't think we should describe such obvious things. > And there is already text in RFC 7296 with similar meaning > in section 2.21 (however, without using imperative words): > > There are many kinds of errors that can occur during IKE processing. > The general rule is that if a request is received that is badly > formatted, or unacceptable for reasons of policy (such as no matching > cryptographic algorithms), the response contains a Notify payload > indicating the error. > > (Note singular "the response", not "the responses").
This is true when sending a response. This is not the case we are talking about. This implementation will start completely new INFORMATIONAL exchange after the IKE_SA_INIT times out. I.e., attacker sends IKE_SA_INIT request, server responds to this, and then nothing comes through later. Then the responder will time out the IKE_SA_INIT because it is half open IKE SA, and starts to do something on it. In one case we have seen responder initiating completely new INFORMATIONAL exchange with private error code inside. I.e., this was not a response, it was new request with new message id etc, and this request was then retransmitted as RFC7296 specifies for several times, before it timed out. This exchange was completely in clear as the IKE SA was not yet finished. In another case the responder again started new INFORMATIONAL exchange, but in this the original responder sent encrypted delete payload for the half open IKE SA, and this message was retransmitted only once, i.e. only two packets were sent. The original initiator receiving encrypted and MACed delete notification for IKE SA it is trying to negotiate (lets say the IKE_AUTH never reached the responder as they were so big that IP layer fragmented them and then some network device dropped them) will know that this is from the node it has talked to in IKE_SA_INIT, so there is no reason not to act on that delete. Both of those were using new exchanges, which means they were NOT against the RFC7296, but especially the first one sending 20+ retries for the private error notification message was causing amplification factor. The second case is actually quite good compromize to recover from cases where some extraordinary case might cause half open IKE SA to be formed and not causing real amplification for attackers. Anyways I think the first case is clearly a implementation misfeature, and they should fix it. The second case is implementation feature, which might be usable in certain environments. And they might have rate limiters on it. > In your example there is a clear configuration error, and I don't think > we could do anything about this on RFC level. Yes. We do not need to try to cover configuration errors and their effect on DDoS. > Could you please describe how you exhaust the pool of IP addresses? > If you are authenticated user you'll receive the same IP address no matter > how many times you ask for it (in general it depends on SGW implementation, > I assume SGW links client ID with IP from poll). I was about to point exactly that. > If you use NULL auth, then it is a different story, but I think > RFC 7619 describes the risks of using NULL auth. Of course if you are giving address to NULL auth clients then the situation might be different, but 10.0.0.0/8 network has quite a lot of addresses you can give out, before you exhaust the pool. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
