Re: [IPsec] DH Tests draft - failure behavior

Yaron Sheffer <> Tue, 12 March 2013 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0665021F8BBD for <>; Tue, 12 Mar 2013 13:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.829
X-Spam-Status: No, score=-100.829 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Dv-9T+k3lKH for <>; Tue, 12 Mar 2013 13:40:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c01::232]) by (Postfix) with ESMTP id 3FB4321F89AE for <>; Tue, 12 Mar 2013 13:40:44 -0700 (PDT)
Received: by with SMTP id g14so97137eak.37 for <>; Tue, 12 Mar 2013 13:40:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Uon0Vz0iQMsA0eIYAQkD7y/XKXMWn7lFbkKm/O8FKxs=; b=Ts2crBt7/xJZGjgk6RVep8PZuglU0WVPVgiW6n4jo1C5egnW4g+khiZRyVsSkp/OyN JSDam9O+ko/kgfsui2GpkCO26h94G930wbBNF8H0AUdtMwjxodWmK6Z5+R0Mdcj5rhTt nGbVK/mbvJ19gTa+W2RGoChju4DDz0wOkytRWtl0nfcqWnB01bMNteqmA8+8gnsbMQO4 VCa0OcekL2SQvSmqW3+E3aFkDwsVUtbcUtZIXtOwDfnGrmMbaxooBsmpvvIV8UsqXo5q BEm4TdVfN+WolU35THlE5Szlg5cMarBJfSoE0EIHjcucdD4Uw8fg9ritemLzs3WfjESk CX0w==
X-Received: by with SMTP id bn50mr51343955eeb.36.1363120843383; Tue, 12 Mar 2013 13:40:43 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id 3sm31896080eej.6.2013. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 13:40:42 -0700 (PDT)
Message-ID: <>
Date: Tue, 12 Mar 2013 22:40:39 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Tero Kivinen <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1255"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IPsecme WG <>
Subject: Re: [IPsec] DH Tests draft - failure behavior
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Mar 2013 20:40:45 -0000

Hi Tero,

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

Referring to, 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.


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.