Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions
draft-ietf-grow-geomrt-07.txt

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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 27, 2012.

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. Requirements notation
• 2. Introduction
• 3. Definitions
• 4. Geo-location aware MRT Routing Information Subtype
• 4.1. GEO_PEER_TABLE
• 4.2. GEO_PEER_TABLE and peer entry values.
• 5. BGP Collector Construction
• 6. Privacy Considerations
• 7. Acknowledgements
• 8. IANA Considerations
• 9. Security Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Author's Address

1. 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].

2. 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) format" [I-D.ietf-grow-mrt]. The MRT format was originally defined in the Multi-threaded Routing Toolkit 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 tererestrial insight to the routes seen by a BGP speaker. Such data may ultimately aid reserachers 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 anomolies. Such insight could provide future input into network design or network security.

This memo documents an optional extension to the "MRT format" [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT subtype field that includes the terestrial coordinates of a BGP Collector and its BGP Peers.

3. Definitions

Coordinates: A set of geographic latitude and longitude specifying a location on the Earth.

BGP Speaker: A network device which 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 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 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" [I-D.ietf-grow-mrt].

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, Peer Count are as defined by the TABLE_DUMP_V2 PEER_INDEX_TABLE format. [I-D.ietf-grow-mrt].

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 coordinate 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format of the peer entries is shown below. The Peer Type and the Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT [I-D.ietf-grow-mrt] PEER_INDEX_TABLE format. The order of the Peer entries in 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                        |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 coordinate and NAN values for a single Peer.

4.2. GEO_PEER_TABLE and peer entry values.

Collector BGP ID: Defined in the MRT format [I-D.ietf-grow-mrt]

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 [I-D.ietf-grow-mrt]

Peer entries: Defined in the MRT format [I-D.ietf-grow-mrt]

Peer Type: Defined in the MRT format [I-D.ietf-grow-mrt]

Peer BGP ID: Defined in the MRT format [I-D.ietf-grow-mrt]

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 is to aid the reader in understanding the function of a BGP collector.

The BGP Collector is a device (hardware or software based) which speaks the Border Gateway Protocol and its intended function is to store (and archive) the BGP routing data it receives from other BGP speakers it has peering relationships with, 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 nor 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 iBGP, 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 a 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 Bluck, 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

This section requests the Internet Assigned Numbers Authority (IANA) register the additional Subtype code value as:

    7    GEO_PEER_TABLE

in the "MRT format" [I-D.ietf-grow-mrt] and Subtype code values related to the TABLE_DUMP_v2 type in the MRT namespace.

9. Security Considerations

This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields that are of a descriptive nature and provide 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 organisation 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 geolocation data supplied by a peer can only be taken at face value. It is possible that a BGP peer may supply coordinates that is purposefully misleading or inaccurate. It is therefore up to the BGP Collector to include this information or not, 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

10.2. Informative References

Author's Address