Re: [IPsec] DH Tests draft - failure behavior

[Yaron Sheffer <[e-mail]>]

Hi Tero,

I think this case should be handled exactly like any badly formatted 
message.

Referring to http://tools.ietf.org/html/rfc5996#section-2.21.1, we did 
not mandate sending errors back, but it is implied in the text. And yes, 
the receiver is free to ignore these errors for the reasons you cite. In 
fact there's no obvious remedial action anyway, similarly to "invalid 
syntax", the error basically indicates a bug. So sending this error just 
helps in debugging the sender and nothing more. But IMHO this is still a 
good reason to send it.

Thanks,
	Yaron

On 03/12/2013 07:44 PM, Tero Kivinen wrote:
> 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.
>