MRT geo-location: Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions
An optional MRT record type that adds latitude and longitude for a BGP collector and its peers.
Manderson, T., "Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions", RFC 6397, DOI 10.17487/RFC6397, October 2011, <https://www.rfc-editor.org/info/rfc6397>.
@misc{rfc6397,
series = {Request for Comments},
number = 6397,
howpublished = {RFC 6397},
publisher = {RFC Editor},
doi = {10.17487/RFC6397},
url = {https://www.rfc-editor.org/info/rfc6397},
author = {T. Manderson},
title = {{Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions}},
pagetotal = 8,
year = 2011,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) T. Manderson
Request for Comments: 6397 ICANN
Category: Standards Track October 2011
ISSN: 2070-1721
Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP)
Routing Information Export Format with Geo-Location Extensions
Abstract
This document updates the Multi-threaded Routing Toolkit (MRT) export
format for Border Gateway Protocol (BGP) routing information by
extending it to include optional terrestrial coordinates of a BGP
collector and its BGP peers.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6397.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Geo-Location-Aware MRT Routing Information Subtype . . . . . . 3
4.1. GEO_PEER_TABLE . . . . . . . . . . . . . . . . . . . . . . 3
4.2. GEO_PEER_TABLE and Peer Entry Values . . . . . . . . . . . 5
5. BGP Collector Construction . . . . . . . . . . . . . . . . . . 5
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction
Researchers and engineers often wish to analyze network behavior by
studying routing protocol transactions and routing information base
snapshots in relation to geographical topologies. Usually, the
Border Gateway Protocol [RFC4271] is the subject of study, and the
analysis can be significantly aided by the availability and extension
of the "Multi-Threaded Routing Toolkit (MRT) Routing Information
Export Format" [RFC6396]. The MRT format was originally defined in
the MRT Programmer's Guide [MRT-GUIDE].
The addition of geo-location coordinates (longitude and latitude)
pertaining to the geographical location of both the BGP collector and
its BGP peers to BGP export data enables a researcher or enquiring
individual to gain a terrestrial insight to the routes seen by a BGP
speaker. Such data may ultimately aid researchers in understanding
any disparity between the geographical location of networks and the
topological location of networks in addition to the relationships
between geographical position and routing anomalies. Such insight
could provide future input into network design and network security.
This memo documents an optional extension to the MRT format [RFC6396]
and introduces an additional definition of an MRT Subtype field that
includes the terrestrial coordinates of a BGP collector and its BGP
peers.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Definitions
Coordinates: The geographic latitude and longitude specifying a
location on the earth.
BGP Speaker: A network device that exchanges network routing
information using BGP.
Geo-location: Assigning a set of coordinates to a specific artifact,
in this case a BGP speaker.
BGP Collector: A BGP speaker (usually passive) that stores and
archives BGP routing data from active BGP peers for analysis.
BGP Peer: Either an internal or external BGP peer [RFC4271].
Not A Number (NAN): Numeric data type representing an undefined or
unrepresentable value, as defined in the IEEE Standard for Floating-
Point Arithmetic [IEEE754].
4. Geo-Location-Aware MRT Routing Information Subtype
An additional subtype (GEO_PEER_TABLE) is defined for the
TABLE_DUMP_V2 format, extending TABLE_DUMP_V2 Type.
4.1. GEO_PEER_TABLE
The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_V2 Types to include
geo-location information in the form of the World Geodetic System
1984 (WGS84) [WGS-84] formatted coordinates.
The document adds the 7th subtype number and name below. The first 6
subtypes are defined by the MRT format [RFC6396].
Subtype Number Subtype Name
----------------------------------
7 GEO_PEER_TABLE
The GEO_PEER_TABLE MRT record provides the BGP ID of the collector,
its latitude and longitude in WGS84 [WGS-84] format, and a list of
indexed peers and their respective latitudes and longitudes in WGS84
[WGS-84] format.
The format and function of the Collector BGP ID and Peer Count are as
defined by the TABLE_DUMP_V2, PEER_INDEX_TABLE format [RFC6396].
The Collector Latitude and Collector Longitude are the geographical
coordinates of the collector in WGS84 [WGS-84] datum decimal degrees
format stored as a single precision float in the 32 bits allocated to
the Collector Latitude and Collector Longitude. The latitude and
longitude MAY be a Not A Number (NAN) [IEEE754] for situations where
the geo-location of the collector is considered private. The
Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84
[WGS-84] datum coordinates and NAN values.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collector Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Count | Peer Entries (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of the GEO_PEER_TABLE
The format of the Peer Entries is shown below. The Peer Type and the
Peer BGP ID are as defined in the TABLE_DUMP_V2 MRT, PEER_INDEX_TABLE
format [RFC6396]. The order of the Peer Entries in the
GEO_PEER_TABLE MUST match the order and number as existing in the
PEER_INDEX_TABLE.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Latitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of Peer Entries
The Peer Latitude and Peer Longitude are the geographical coordinates
of the peer in WGS84 [WGS-84] datum decimal degrees format stored as
a single precision float in the 32 bits allocated to the Peer
Latitude and Peer Longitude. The latitude and longitude MAY be a Not
A Number (NAN) [IEEE754] for situations where the geo-location of the
peer is considered private. The Peer Latitude and Peer Longitude
MUST NOT be a mix of WGS84 [WGS-84] datum coordinates and NAN values
for a single peer.
4.2. GEO_PEER_TABLE and Peer Entry Values
Collector BGP ID: Defined in the MRT format [RFC6396].
Collector Latitude: Geographic latitude of the BGP collector in WGS84
[WGS-84] datum decimal degrees format stored as a single precision
float.
Collector Longitude: Geographic longitude of the BGP collector in
WGS84 [WGS-84] datum decimal degrees format stored as a single
precision float.
Peer Count: Defined in the MRT format [RFC6396].
Peer Entries: Defined in the MRT format [RFC6396].
Peer Type: Defined in the MRT format [RFC6396].
Peer BGP ID: Defined in the MRT format [RFC6396].
Peer Latitude: Geographic latitude of the BGP peer in WGS84 [WGS-84]
datum decimal degrees format stored as a single precision float.
Peer Longitude: Geographic longitude of the BGP peer in WGS84
[WGS-84] datum decimal degrees format stored as a single precision
float.
5. BGP Collector Construction
This section aids the reader in understanding the function of a BGP
collector.
The BGP collector is a hardware- or software-based device that speaks
the Border Gateway Protocol. Its intended function is to store (and
archive) the BGP routing data it receives from other BGP speakers
with which it has peering relationships, providing data for later
analysis. The general nature of a BGP collector is that it is a
passive device in that it listens to route updates and does not
announce or propagate any information it knows or receives. It
should be noted that this is not always the case; network operators
sometimes enable the collection of BGP routing data on active BGP
speakers to obtain a situational view of the routing system as they
see it at a particular point in time.
As a fully fledged BGP speaker, the BGP collector can fit into any
BGP topology including Internal BGP (iBGP), External BGP (eBGP), and
so on. The implementation of a BGP collector in a network topology
is therefore limited by that network's use of BGP.
6. Privacy Considerations
The GEOPRIV [RFC6280] architecture requires that privacy rules
attached to a location object be transmitted alongside the location
information in the object. If a BGP collector adds location
coordinates to an MRT record based on GEOPRIV location objects, then
it would have to include privacy rules as well. Since the MRT geo-
location format does not support the provision of privacy rules, each
location entry in an MRT object is assigned the following default
privacy rules [RFC4119]:
-- retransmission-allowed: True
-- retention-expires: 100 years from timestamp of the MRT object
-- ruleset-reference: Empty
-- note-well: Empty
Location information derived from a location object with more
restrictive privacy rules MUST NOT be included in an MRT geo-location
record unless there are non-technical measures in place that enforce
and communicate the constraints on the use of the location
information in the MRT geo-location format (e.g., contractual
agreements between peers).
7. Acknowledgements
Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Blunk, Richard
Barnes, and Jeffrey Haas for reviewing this document.
This document describes a small portion of the research towards the
author's Ph.D.
8. IANA Considerations
Per this section, the Internet Assigned Numbers Authority (IANA) has
registered the additional Subtype code value as:
7 GEO_PEER_TABLE
in the MRT format [RFC6396] and Subtype code values related to the
TABLE_DUMP_V2 Type in the MRT namespace.
9. Security Considerations
This extension to the MRT format [RFC6396] defines fields that are of
a descriptive nature and provides information that is useful in the
analysis of routing systems. As such, the author believes that they
do not constitute an additional network-based security risk. It is
recommended that the operators of the BGP collector and BGP peers
consider their own privacy and security concerns before supplying
geographical coordinates to BGP data collection systems. Special
attention should be given to the physical security of an organization
before supplying geographical coordinates, especially if the
resulting BGP data with geo-location extensions is made public.
Entities that operate BGP collectors, and users of data provided by
BGP collectors, should be aware that the geo-location data supplied
by a peer can only be taken at face value. It is possible that a BGP
peer may supply coordinates that are purposefully misleading or
inaccurate. It is therefore up to the BGP collector whether or not
to include this information or use its own methods to either trust or
validate the data provided. It is not recommended that a BGP
collector use geographical coordinates not supplied by a BGP peer.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011.
[RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded
Routing Toolkit (MRT) Routing Information Export
Format", RFC 6396, October 2011.
10.2. Informative References
[IEEE754] IEEE 754, "IEEE Standard for Floating-Point Arithmetic",
August 2008, <http://ieeexplore.ieee.org/servlet/
opac?punumber=4610933>.
[MRT-GUIDE] Labovitz, C., "MRT Programmer's Guide", November 1999,
<http://www.merit.edu/networkresearch/
mrtprogrammer.pdf>.
[WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic
System 1984", January 2000, <http://earth-info.nga.mil/
GandG/publications/tr8350.2/wgs84fin.pdf>.
Author's Address
Terry Manderson
ICANN
EMail: terry.manderson@icann.org
AI ELI5
On this page
§1Why Add Locations to Routing Data
Researchers and engineers often study routing protocol transactions and routing table snapshots in relation to geography. Usually the subject is BGP (RFC 4271), and the data is stored in the MRT format of RFC 6396.
Adding the longitude and latitude of a BGP collector and its BGP peers gives a terrestrial view of the routes a BGP speaker sees. The RFC says this may help researchers understand the gap between where networks are located and where they sit in the topology, and the link between geographic position and routing anomalies. It could also inform future network design and network security.
The memo describes an optional extension to MRT and defines one new Subtype that carries the coordinates.
People who study the internet want to know where routers are on a real map, not just how they are connected. This adds that missing piece to the saved files.
§2Collectors and Peers
A BGP speaker is a device that exchanges routing information using BGP. A BGP collector is a speaker, usually passive, that stores and archives BGP routing data from active BGP peers for analysis. A BGP peer can be internal or external.
The RFC also explains how a collector works. It is a hardware or software device that speaks BGP and stores the routing data it receives from the speakers it peers with. Typically it only listens to route updates and does not announce or propagate anything. This is not always so: operators sometimes turn on collection on active BGP speakers to get a view of the routing system as they see it at one moment. As a full BGP speaker, a collector can fit into any BGP topology, including iBGP and eBGP.
A collector is like a quiet note-taker in a room full of routers who are chatting. It writes down what it hears and usually does not talk back.
§3The GEO_PEER_TABLE Record
The extension adds subtype number 7, GEO_PEER_TABLE, to the TABLE_DUMP_V2 type. The first six subtypes are the ones defined in RFC 6396. The record gives the BGP ID of the collector, its latitude and longitude, and a list of indexed peers with their own latitudes and longitudes.
The Collector BGP ID and Peer Count work as in the PEER_INDEX_TABLE of RFC 6396. After them come the peer entries. Each peer entry holds the Peer Type and Peer BGP ID, as defined in RFC 6396, followed by a 32-bit Peer Latitude and a 32-bit Peer Longitude. The entries in the GEO_PEER_TABLE MUST match the order and number of those in the PEER_INDEX_TABLE.
All coordinates are in WGS84 datum decimal degrees, stored as a single precision float in 32 bits.
It is a list with one line per router: its name tag, then two numbers that say how far north or south and east or west it is on the map. The lines must be in the same order as in the earlier list of peers.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
COLLECTOR-BGP-ID | Collector BGP ID | 4 bytes | As defined for PEER_INDEX_TABLE in RFC 6396. | |
COLLECTOR-LAT | Collector Latitude | 4 bytes | WGS84 decimal degrees, single precision float, or NAN if private. | |
COLLECTOR-LON | Collector Longitude | 4 bytes | WGS84 decimal degrees, single precision float, or NAN if private. | |
PEER-COUNT | Peer Count | 2 bytes | Number of peer entries that follow. |
§4Private Locations and Privacy Rules
A latitude and longitude MAY be a Not A Number (NAN) value, as defined in IEEE 754, when the location of the collector or peer is considered private. A pair MUST NOT mix real coordinates with NAN, so both are real or both are NAN, for the collector and for each peer.
The RFC also covers the GEOPRIV architecture (RFC 6280), which requires privacy rules to travel with location information. MRT geo-location has no place for such rules, so each location entry gets default rules in the style of RFC 4119: retransmission-allowed is True, retention-expires is 100 years from the timestamp of the MRT object, and ruleset-reference and note-well are empty.
Location information from an object with more restrictive rules MUST NOT go into an MRT geo-location record unless non-technical measures, such as contractual agreements between peers, enforce and communicate the limits on its use.
If someone does not want to share where their router is, they can write "not a number" instead of real map numbers. And if a location came with strict rules, it cannot be put in the file unless there is an agreement to follow them.
§5Security and Registration
The new fields are descriptive, and the author believes they do not add a network-based security risk. Operators of collectors and peers are advised to think about their own privacy and security before supplying coordinates, with special attention to physical security if the resulting data is made public.
Coordinates supplied by a peer can only be taken at face value, because a peer may supply purposefully misleading or inaccurate values. It is up to the collector whether to include the data or to use its own methods to trust or validate it. The RFC does not recommend that a collector use coordinates that a BGP peer did not supply.
IANA registered the new subtype value 7, GEO_PEER_TABLE, in the MRT namespace for the TABLE_DUMP_V2 type.
Location numbers are just what the router says about itself, and it could fib. So the note-taker decides how much to believe them, and nobody should be forced to reveal where a building is.