[IPsec] IKE_INIT spoofing from SaudiNet and Zain Data-Jordan ?

Paul Wouters <paul@nohats.ca> Mon, 03 December 2018 16:55 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7751B130EE9 for <ipsec@ietfa.amsl.com>; Mon, 3 Dec 2018 08:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5uPFFiLStJS for <ipsec@ietfa.amsl.com>; Mon, 3 Dec 2018 08:55:46 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D9B130E0E for <ipsec@ietf.org>; Mon, 3 Dec 2018 08:55:46 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 437rj713ZZzMWS for <ipsec@ietf.org>; Mon, 3 Dec 2018 17:55:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1543856139; bh=Gd+b2YgTP256Hvg6p6PvwphUUEhak1/174R6JuSFMyE=; h=Date:From:To:Subject; b=ZkAIaHS+4LgbRn++zHGSASbx678w/cyDkN/l2KAjjLjVCBpudiA8mQn5K8XQJvS8Y g1shqEY+JhriRmx3DRta8muYU+xih4R7tMoc3AJKOf/vJUYI9YeF7g3VAxM/UyKmgl FIf6KBNehvubzjg5nyhUfjyhFdKNmmxdGk45u3xo=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wsc7EQ2n6U8A for <ipsec@ietf.org>; Mon, 3 Dec 2018 17:55:37 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <ipsec@ietf.org>; Mon, 3 Dec 2018 17:55:37 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3641412EAE4; Mon, 3 Dec 2018 11:55:36 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3641412EAE4
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2CAD140D37F8 for <ipsec@ietf.org>; Mon, 3 Dec 2018 11:55:36 -0500 (EST)
Date: Mon, 03 Dec 2018 11:55:36 -0500
From: Paul Wouters <paul@nohats.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
Message-ID: <alpine.LRH.2.21.1812031149290.29087@bofh.nohats.ca>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/GMX9t7fchX-ABAtuUS78fdDTews>
Subject: [IPsec] IKE_INIT spoofing from SaudiNet and Zain Data-Jordan ?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2018 16:55:49 -0000

Hi,

I've seen reports where our software receives IKE_AUTH requests without
the preceeding IKE_INIT request. After some debugging, it seems that
two networks, SaudiNet and Zain Data-Jordan, sometimes MITM the IKE_INIT
by replying (and I guess generating a IKE SPI for the responder) and
then step away to let the IKE_AUTH fail, since the responder never
received the original IKE_INIT.

Has anyone else seen this as well? Is this some surveilance tool that
is being buggy, or is this behaviour the intended result? It seems to
be happening intermittently.

Paul, almost curious enough to hack in an IKE_INIT request in an IKE_AUTH
marked exchange packet :P