[IPsec] DH Tests draft - failure behavior

[Tero Kivinen <[e-mail]>]

Yaron Sheffer writes:
> Following up on the discussion we just had:
> 
> Paul raised the question whether we should respond with an error message 
> in case any of the tests fail. We know from many examples that errors 
> can reveal secret information.
> 
> However in this particular case:
> 
> - All IKEv2 DH groups are public information.
> - All of the proposed tests only depend on public information, plus the 
> information received from the sender in the clear. In other words, the 
> test could just as well be performed by an eavesdropper.
> 
> The only thing that such an error message does reveal is that the 
> receiver implements the test, but this is something that an attacker can 
> find out anyway.
> 
> Which is why I think we should treat such failures as a normal syntax 
> error, and respond with an error message, as a courtesy to the sender.
> 
> We should make these considerations explicit in the draft, specifically 
> that the groups are well known.

On the other hand failure there means we didn't manage to negotiate
shared secret, thus the whatever error message we sent out must be
unauthenticated. The recipient of such unauthenticated notify cannot
act directly on it, as attacker might have sent it instead of the real
peer, and real peer might actually take some time to do the checks and
other calculations before answering. Befcause of this sending the
notification does not help that much, it only opens new way to do DoS
attack. As this error cannot happen in valid implementations, it is
always either attack or implementation working incorrectly, I see no
point of making special code for error messages in that case.

My recommendation is that the recipient will simply silently ignore
the IKE_SA_INIT packet having invalid KE payload. It MAY continue
keep setting up the SA, i.e. see if there is properly formatted and
generated KE payload in the future. Otherwise the attacker could again
do DoS attack against the peer, by sending there IKE_SA_INIT response
with invalid KE payload and cause inititor to drop the connection
before the real responder have time to reply. 
-- 
[e-mail]