[secdir] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt

Phillip Hallam-Baker <hallam@gmail.com> Sat, 13 February 2010 02:26 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74E928C263; Fri, 12 Feb 2010 18:26:32 -0800 (PST)
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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4ug-1eXejsy; Fri, 12 Feb 2010 18:26:31 -0800 (PST)
Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 3505E28C133; Fri, 12 Feb 2010 18:26:31 -0800 (PST)
Received: by pzk5 with SMTP id 5so4689467pzk.29 for <multiple recipients>; Fri, 12 Feb 2010 18:27:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=qQ6bEIjBci1YZ1sOYi8n+vkHY5qL/xkr9QV6t6Vp8Ig=; b=FMGSJBEeVKgbwEdLC4YaEkJivSu12QKM0o73DfewS0Vp7AblFuVyfRzLKJwKSk3Yqh KCBWGTWQFXDG11aE3AzFdJD/z0DIiTdsKGEkHMnPeHcK7mVM5K6h7dKpS7NWryNJ10/A wsdCZpTchVeB26rZa2Ne+A6BY5bq332b3lI0A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TukWgUiZY/LQg9PKFD/rSnNEhVY96OHV6C46BSX2JSQS5guawqFjv0E7hHHtrtetLS bbyKTSer2ecgp5paS8Nq4AXP/sbaU5yVydzG27o6uCbnD3T0xzXjw9+fS11AUgX56S45 RHVCKv4gYvEPoVDMyUjs+xwAFMq2Y4QcudB0g=
MIME-Version: 1.0
Received: by 10.115.2.20 with SMTP id e20mr1529649wai.50.1266028069451; Fri, 12 Feb 2010 18:27:49 -0800 (PST)
Date: Fri, 12 Feb 2010 21:27:49 -0500
Message-ID: <a123a5d61002121827y2f2b0256u5859790c06819a92@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: secdir@ietf.org, fernando@gont.com.ar, tcpm@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [secdir] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Feb 2010 02:26:33 -0000

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

ICMP is one of those IP layer protocols that we all have some idea
exist even if only the network level people understand what they do.
This document is designed to describe security issues arising from the
ICMP protocol and commonly implemented counter-measures.

The principal security risks considered are service risks. ICMP may be
used to perform certain denial of service and performance downgrade
attacks. As such it probably needs rather more justification than 'we
have always done this' when building critical infrastructures.


Overall,

Given that TCP streams will eventually time-out, I have something of a
hard time seeing why we would be using a non-authenticated control
protocol at all. Yes, I know the legacy reasons etc. etc. But this is
not the way we would approach this problem today. This argument is
almost made on page 15. Some statement giving the case for taking
notice of ICMP messages at all is in order. It might well be that an
appropriate control in certain cases would be to turn off ICMP hard
errors and rely on timeouts, I am thinking here of critical
infrastructure applications and communications between hosts running
BGP functions.

In particular I note that the draft says "It is interesting to note
that, as ICMP error messages are transmitted unreliably, transport
protocols should not depend on them for correct functioning."

Given the extreme approach to security of starting from nothing and
only adding systems that are essential, this would seem to suggest
ICMP is not necessary and could be eliminated. There may be a case to
the contrary but it needs to be made before page 15.


Page 15/16

The following phrase repeats in a way that suggests an editing oversight:
aborting the
   connection would be to ignore the valuable feature of the Internet
   that for many internal failures it reconstructs its function without
   any disruption of the end points

Page 24-26

A more general way of describing the mitigation strategy would be to
point out the general principle that error messages may be ignored
whenever a packet indicating success is received within the timeout
window. In other words no final processing decisions should be made on
an unauthenticated ICMP packet until after the timeout window expires.


-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/