[MMUSIC] ICE TCP and TCP amplification attack (mitigation)
Ari Keranen <ari.keranen@nomadiclab.com> Thu, 19 May 2011 14:29 UTC
Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C38E06C9 for <mmusic@ietfa.amsl.com>; Thu, 19 May 2011 07:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFKbi205VKSL for <mmusic@ietfa.amsl.com>; Thu, 19 May 2011 07:29:37 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id B83D1E067B for <mmusic@ietf.org>; Thu, 19 May 2011 07:29:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 5806E4E6D8 for <mmusic@ietf.org>; Thu, 19 May 2011 17:29:27 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iISstq8ccGTy for <mmusic@ietf.org>; Thu, 19 May 2011 17:29:26 +0300 (EEST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 4717A4E6BD for <mmusic@ietf.org>; Thu, 19 May 2011 17:29:26 +0300 (EEST)
From: Ari Keranen <ari.keranen@nomadiclab.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 May 2011 17:29:26 +0300
Message-Id: <F47EF2BF-FF8B-4E28-BC9D-F2258790BBE5@nomadiclab.com>
To: mmusic WG <mmusic@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [MMUSIC] ICE TCP and TCP amplification attack (mitigation)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2011 14:29:37 -0000
Hi all, Flemming identified a possible TCP amplification attack in ICE TCP: On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: > - Section 12 > I believe there is a TCP amplification attack similar to the STUN amplification attack that requires consideration, since the TCP connection is established prior to any STUN/ICE checks and involves TCP state creation on the part of the attacked party. That is, an attacker could put in the SDP offer a set of passive reflexive candidates with the address of the victim and the answerer would make a bunch of TCP connections towards the victim. A possible mitigation, as Flemming suggested, would be to limit the number of outstanding TCP connection attempts to the same IP-address. That sounds reasonable to me, since having many (un-frozen) candidates from the same IP address seem unlikely anyway, but are there any other ideas? Cheers, Ari