Last Call Review of draft-ietf-grow-mrt-

Request Review of draft-ietf-grow-mrt
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-09-24
Requested 2010-09-11
Authors Larry Blunk, Craig Labovitz, Manish Karir
Draft last updated 2010-09-15
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes 
State Completed
Review review-ietf-grow-mrt-secdir-lc-barnes-2010-09-15
Review completed: 2010-09-15


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  


[1] <

[2] <