Skip to main content

Last Call Review of draft-ietf-grow-mrt-
review-ietf-grow-mrt-secdir-lc-barnes-2010-09-15-00

Request Review of draft-ietf-grow-mrt
Requested revision 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
I-D last updated 2010-09-15
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes
State Completed
Request Last Call review on draft-ietf-grow-mrt by Security Area Directorate Assigned
Completed 2010-09-15
review-ietf-grow-mrt-secdir-lc-barnes-2010-09-15-00
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

>