[secdir] SECDIR review of draft-atlas-icmp-unnumbered-06

"Hallam-Baker, Phillip" <pbaker@verisign.com> Mon, 09 February 2009 20:55 UTC

Return-Path: <pbaker@verisign.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 B65203A6BA5; Mon, 9 Feb 2009 12:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.417
X-Spam-Level:
X-Spam-Status: No, score=-5.417 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 UZgR1WOLNkWm; Mon, 9 Feb 2009 12:55:36 -0800 (PST)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id DF2013A6B07; Mon, 9 Feb 2009 12:55:36 -0800 (PST)
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n19KtVS5027619; Mon, 9 Feb 2009 12:55:31 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 12:55:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98AF8.BDFDCE3A"
Date: Mon, 09 Feb 2009 12:55:30 -0800
Message-ID: <2788466ED3E31C418E9ACC5C3166155768B26A@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: SECDIR review of draft-atlas-icmp-unnumbered-06
Thread-Index: AcmK91KuUl4zofcQQYiVxsu1xXj+qQ==
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: alia.atlas@bt.com, rbonica@juniper.net, naiming@cisco.com, enkechen@cisco.com, secdir@ietf.org, iesg@ietf.org
X-OriginalArrivalTime: 09 Feb 2009 20:55:30.0772 (UTC) FILETIME=[BE671940:01C98AF8]
Subject: [secdir] SECDIR review of draft-atlas-icmp-unnumbered-06
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: Mon, 09 Feb 2009 20:55:37 -0000

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 goal of the document is to provide a mechanism that allows routers or hosts to supply additional information in responses that may be useful for troubleshooting and debugging.
 
As such the document has the standard security recitals with respect to the disclosure of information that may compromise the security of the network. I believe these warnings to be adequate and the risk of the additional information disclosure to be low since the purpose of this particular mechanism is to provide a reliable means of obtaining information that an attacker could otherwise guess or obtain through heuristics. So the additional exposure of information is likely to be marginal at best.
 
The security considerations do not address the issue of authenticating the response data. While the intended field of use is administrative debugging, we have in the past observed attempts to develop protocols that employ traceroute for selection amongst available host (sonar et. al.). One can imagine a situation in todays internet where such a mechanism might be abused by an attacker in order to direct traffic onto particular networks and thus make possible a DoS attack.
 
A security consideration warning not to use the protocol in such a fashion should be sufficient.