[secdir] Security review of draft-shore-icmp-aup-06

"Hilarie Orman" <hilarie@purplestreak.com> Wed, 13 November 2013 07:44 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EC511E8113; Tue, 12 Nov 2013 23:44:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC2pu0ITVveE; Tue, 12 Nov 2013 23:44:10 -0800 (PST)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF1D11E810E; Tue, 12 Nov 2013 23:44:10 -0800 (PST)
Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1VgV7R-00010b-5s; Wed, 13 Nov 2013 00:44:09 -0700
Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1VgV7O-0001bG-Gr; Wed, 13 Nov 2013 00:44:09 -0700
Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id rAD7hr1r002179; Wed, 13 Nov 2013 00:43:53 -0700
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id rAD7hqQg002177; Wed, 13 Nov 2013 00:43:52 -0700
Date: Wed, 13 Nov 2013 00:43:52 -0700
Message-Id: <201311130743.rAD7hqQg002177@sylvester.rhmr.com>
From: Hilarie Orman <hilarie@purplestreak.com>
To: draft-shore-icmp-aup@tools.ietf.org
X-XM-AID: U2FsdGVkX1+D0nx641CQI/B+errFi7sl
X-SA-Exim-Connect-IP: 72.250.219.84
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: *;draft-shore-icmp-aup@tools.ietf.org
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] Security review of draft-shore-icmp-aup-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 13 Nov 2013 07:44:16 -0000

Security review of draft-shore-icmp-aup-06
An Acceptable Use Policy for New ICMP Types and Codes

Do not be alarmed.  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.

The document discusses the current uses of ICMP and how it may or may
not fit into management or control planes, depending on your view of
what those are.  The recommendation is to limit uses to reporting
downstream forwarding anomalies, discovering on-link routers and hosts
and network parameters.  "ICMP should not be used as a routing or
network management protocol."

While there are ostensibly no new security considerations, it is
worthwhile noting that ICMP plays a part in the Photuris protocol and
was also used in SKIP (though that usage is deprecated).  In general,
I have some concern about using ICMP to discover network security
parameters or to report on network security anomalies in the
forwarding plane.

I would recommend adding something to the security considerations
about avoiding such usage or using special caution if defining
new protocols.

Hilarie