draft-ietf-grow-mrt-14.txt   draft-ietf-grow-mrt-15.txt 
Network Working Group L. Blunk Network Working Group L. Blunk
Internet-Draft M. Karir Internet-Draft M. Karir
Intended status: Informational Merit Network Intended status: Informational Merit Network
Expires: October 22, 2011 C. Labovitz Expires: January 7, 2012 C. Labovitz
Arbor Networks Deepfield Networks
April 20, 2011 July 6, 2011
MRT routing information export format MRT routing information export format
draft-ietf-grow-mrt-14.txt draft-ietf-grow-mrt-15.txt
Abstract Abstract
This document describes the MRT format for routing information This document describes the MRT format for routing information
export. This format was developed in concert with the Multi-threaded export. This format was developed in concert with the Multi-threaded
Routing Toolkit (MRT) from whence the format takes it name. The Routing Toolkit (MRT) from whence the format takes it name. The
format can be used to export routing protocol messages, state format can be used to export routing protocol messages, state
changes, and routing information base contents. changes, and routing information base contents.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 22, 2011. This Internet-Draft will expire on January 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 21, line 18 skipping to change at page 21, line 18
information data. The fields defined in the MRT specification are of information data. The fields defined in the MRT specification are of
a descriptive nature and provide information that is useful to a descriptive nature and provide information that is useful to
facilitate the analysis of routing data. As such, the fields facilitate the analysis of routing data. As such, the fields
currently defined in the MRT specification do not in themselves currently defined in the MRT specification do not in themselves
create additional security risks, since the fields are not used to create additional security risks, since the fields are not used to
induce any particular behavior by the recipient application. induce any particular behavior by the recipient application.
Some information contained in an MRT data structure might be Some information contained in an MRT data structure might be
considered sensitive or private. For example, a BGP peer that sends considered sensitive or private. For example, a BGP peer that sends
a message to an MRT-enabled router might not expect that message to 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 be shared beyond the AS to which it is sent.
geolocation extension to MRT could reveal the location of an MRT
router's peers [I- D.ietf-grow-geomrt]. An organization that intends Information that could be considered sensitive include BGP peer IP
to use the MRT structure to export routing information beyond the addresses, BGP Next Hop IP addresses, and BGP Path Attributes. Such
domain where it normally accessible (e.g., publishing MRT dumps for information could be useful to mount attacks against the BGP protocol
use by researchers) should verify with any peers whose information and routing infrastructure. RFC 4272 [RFC4272] examines a number of
might be included, and possibly remove sensitive fields. weaknesses in the BGP protocol which could potentially be exploited.
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.
The proposed geolocation extension to MRT could reveal the location
of an MRT router's peers [I- D.ietf-grow-geomrt].
7. References 7. References
7.1. Normative References 7.1. Normative References
[IANA-AF] "Address Family Numbers", [IANA-AF] "Address Family Numbers",
<http://www.iana.org/numbers.html>. <http://www.iana.org/numbers.html>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
skipping to change at page 24, line 5 skipping to change at page 23, line 9
[MRT PROG GUIDE] [MRT PROG GUIDE]
Labovitz, C., "MRT Programmer's Guide", November 1999, Labovitz, C., "MRT Programmer's Guide", November 1999,
<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>. <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997. January 1997.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998. November 1998.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006.
Appendix A. MRT Encoding Examples Appendix A. MRT Encoding Examples
This appendix, which is not a normative reference, contains a MRT This appendix, which is not a normative reference, contains a MRT
encoding examples. encoding examples.
The following example shows the encoding for a MRT record type of The following example shows the encoding for a MRT record type of
BGP4MP and subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS BGP4MP and subtype BGP4MP_MESSAGE_AS4. The Peer AS and Local AS
numbers are encoded in 4 bytes fields due to the use of the numbers are encoded in 4 bytes fields due to the use of the
BGP4MP_MESSAGE_AS4 subtype. The encoded BGP Update is shown in BGP4MP_MESSAGE_AS4 subtype. The encoded BGP Update is shown in
hexadecimal. The AS numbers in the ASPATH in the BGP Update are hexadecimal. The AS numbers in the ASPATH in the BGP Update are
skipping to change at page 35, line 18 skipping to change at page 35, line 18
Merit Network Merit Network
Email: ljb@merit.edu Email: ljb@merit.edu
Manish Karir Manish Karir
Merit Network Merit Network
Email: mkarir@merit.edu Email: mkarir@merit.edu
Craig Labovitz Craig Labovitz
Arbor Networks Deepfield Networks
Email: labovit@arbor.net Email: labovit@deepfield.net
 End of changes. 7 change blocks. 
13 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/