[secdir] secdir review of draft-ietf-grow-mrt

"Richard L. Barnes" <rbarnes@bbn.com> Sun, 12 September 2010 19:03 UTC

Return-Path: <rbarnes@bbn.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 BA63E3A6903; Sun, 12 Sep 2010 12:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level:
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 llIXKVTqyMoA; Sun, 12 Sep 2010 12:03:50 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 8EAA73A6827; Sun, 12 Sep 2010 12:03:50 -0700 (PDT)
Received: from [128.89.254.228] (port=51340 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Ourqa-000BHF-Ej; Sun, 12 Sep 2010 15:04:16 -0400
Message-Id: <0F98AA73-75ED-468B-B16A-9F4D386598F9@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: secdir@ietf.org, iesg@ietf.org, IETF Discussion <ietf@ietf.org>, draft-ietf-grow-mrt@tools.ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 12 Sep 2010 15:04:14 -0400
X-Mailer: Apple Mail (2.936)
Subject: [secdir] secdir review of draft-ietf-grow-mrt
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: Sun, 12 Sep 2010 19:03:51 -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.

This document defines a data format that routers can use to export  
information about routing state (e.g., routing tables), and about  
routing protocol messages that they have received.   The security  
considerations in the document note that the fields in an MRT object  
are descriptive, so because they do not lead to any particular action  
by a recipient, they do not create any security concerns.  This is  
mostly correct.

My only concern is that some of the information in an MRT object could  
be considered private, especially given that MRT is commonly used to  
publish router dumps (e.g., through RouteViews [1]).  For example, BGP  
neighbors that advertise paths to their peers might not expect these  
paths to be published in an MRT dump.  There is also a proposed  
extension to MRT that would add geolocation information about the  
router and its peers [2].  I would suggest that the document add a  
brief note that some information contained in MRT dumps might be  
considered private.  Suggested text based on the above:
"
Some information contained in an MRT data structure might be  
considered sensitive or private.  For example, a BGP peer that sends a  
message to an MRT-enabled router might not expect that message to be  
shared beyond the AS to which it is sent.  The proposed geolocation  
extension to MRT could reveal the location of an MRT router's peers [I- 
D.ietf-grow-geomrt].  An organization that intends to use the MRT  
structure to export routing information beyond the domain where it  
normally accessible (e.g., publishing MRT dumps for use by  
researchers) should verify with any peers whose information might be  
included, and possibly remove sensitive fields.
"

Other than that, I do not believe this document raises any security  
concerns.

[1] <http://www.routeviews.org/>
[2] <http://tools.ietf.org/html/draft-ietf-grow-geomrt-00>