idnits 2.17.1 draft-ietf-grow-geomrt-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 17, 2011) is 4630 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6280' is mentioned on line 248, but not defined == Missing Reference: 'RFC4119' is mentioned on line 255, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-grow-mrt-15 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations Working Group T. Manderson 3 Internet-Draft ICANN 4 Intended status: Standards Track August 17, 2011 5 Expires: February 18, 2012 7 Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) 8 routing information export format with geo-location extensions 9 draft-ietf-grow-geomrt-05.txt 11 Abstract 13 This document updates the Multi-threaded Routing Toolkit (MRT) export 14 format for Border Gateway Protocol (BGP) routing information by 15 extending it to include optional terrestrial coordinates of a BGP 16 Collector and its BGP Peers. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 18, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Geo-location aware MRT Routing Information Subtype . . . . . . 6 56 4.1. GEO_PEER_TABLE . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. GEO_PEER_TABLE and peer entry values. . . . . . . . . . . 7 58 5. BGP Collector Construction . . . . . . . . . . . . . . . . . . 9 59 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 1. Requirements notation 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2119]. 74 2. Introduction 76 Researchers and engineers often wish to analyze network behavior by 77 studying routing protocol transactions and routing information base 78 snapshots in relation to geographical topologies. Usually the Border 79 Gateway Protocol [RFC4271] is the subject of study and the analysis 80 can be significantly aided by the availability and extension of the 81 "Multi-threaded Routing Toolkit (MRT) format" [I-D.ietf-grow-mrt]. 82 The MRT format was originally defined in the Multi-threaded Routing 83 Toolkit Programmer's Guide [MRT-GUIDE]. 85 The addition of geo-location coordinates (longitude and latitude) 86 pertaining to the geographical location of both the BGP collector and 87 its BGP peers to BGP export data enables a researcher or enquiring 88 individual to gain a tererestrial insight to the routes seen by a BGP 89 speaker. Such data may ultimately aide reserachers in understanding 90 any disparity between the geographical location of networks and the 91 topological location of networks in addition to the relationships 92 between geographical position and routing anomolies. Such insight 93 could provide future input into network design or network security. 95 This memo documents an optional extension to the "MRT format" 96 [I-D.ietf-grow-mrt] and introduces an additional definition of a MRT 97 subtype field that includes the terestrial coordinates of a BGP 98 Collector and its BGP Peers. 100 3. Definitions 102 Coordinates: A set of geographic latitude and longitude specifying a 103 location on the Earth. 105 BGP Speaker: A network device which exchanges network routing 106 information using BGP. 108 Geo-location: Assigning a set of coordinates to a specific artifact, 109 in this case a BGP speaker. 111 BGP Collector: A BGP speaker (usually passive) that stores and 112 archives BGP routing data from active BGP peers for analysis. 114 BGP Peer: Either an internal or external BGP peer [RFC4271]. 116 Not A Number (NAN): numeric data type representing an undefined or 117 unrepresentable value. As defined in IEEE Standard for Floating- 118 Point Arithmetic [IEEE754]. 120 4. Geo-location aware MRT Routing Information Subtype 122 An additional subtype (GEO_PEER_TABLE) is defined for the 123 TABLE_DUMP_v2 format, extending TABLE_DUMP_V2 Type. 125 4.1. GEO_PEER_TABLE 127 The GEO_PEER_TABLE Subtype updates the TABLE_DUMP_v2 Types to include 128 Geo-location information in the form of WGS84 [WGS-84] formatted 129 coordinates. 131 The document adds the 7th subtype number and name below. The first 6 132 subtypes are defined by the "MRT format" [I-D.ietf-grow-mrt]. 134 Subtype Number Subtype Name 135 ---------------------------------- 136 7 GEO_PEER_TABLE 138 The GEO_PEER_TABLE MRT record provides the BGP ID of the collector, 139 its latitude and longitude in WGS84 [WGS-84] format, and a list of 140 indexed peers and their respective latitudes and longitudes in WGS84 141 [WGS-84] format. 143 The format and function of the Collector BGP ID, Peer Count are as 144 defined by the TABLE_DUMP_V2 PEER_INDEX_TABLE format. 145 [I-D.ietf-grow-mrt]. 147 The Collector Latitude and Collector Longitude are the geographical 148 coordinates of the collector in WGS84 [WGS-84] datum decimal degrees 149 format stored as a single precision float in the 32 bits allocated to 150 the Collector Latitude and Collector Longitude. The latitude and 151 longitude MAY be a Not A Number (NAN) [IEEE754] for situations where 152 the geo-location of the collector is considered private. The 153 Collector Latitude and Collector Longitude MUST NOT be a mix of WGS84 154 [WGS-84] datum coordinate and NAN values. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Collector BGP ID | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Collector Latitude | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Collector Longitude | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Peer Count | Peer entries (variable) 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Format of the GEO_PEER_TABLE 169 The format of the peer entries is shown below. The Peer Type and the 170 Peer BGP ID is as defined in the TABLE_DUMP_V2 MRT 171 [I-D.ietf-grow-mrt] PEER_INDEX_TABLE format. The order of the Peer 172 entries in GEO_PEER_TABLE MUST match the order and number as existing 173 in the PEER_INDEX_TABLE. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Peer Type | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Peer BGP ID | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Peer Latitude | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Peer Longitude | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Format of peer entries 189 The Peer Latitude and Peer Longitude are the geographical coordinates 190 of the peer in WGS84 [WGS-84] datum decimal degrees format stored as 191 a single precision float in the 32 bits allocated to the Peer 192 Latitude and Peer Longitude. The latitude and longitude MAY be a Not 193 A Number (NAN) [IEEE754] for situations where the geo-location of the 194 peer is considered private. The Peer Latitude and Peer Longitude 195 MUST NOT be a mix of WGS84 [WGS-84] datum coordinate and NAN values 196 for a single Peer. 198 4.2. GEO_PEER_TABLE and peer entry values. 200 Collector BGP ID: Defined in the MRT format [I-D.ietf-grow-mrt] 202 Collector Latitude: Geographic latitude of the BGP collector in WGS84 203 [WGS-84] datum decimal degrees format stored as a single precision 204 float. 206 Collector Longitude: Geographic Longitude of the BGP collector in 207 WGS84 [WGS-84] datum decimal degrees format stored as a single 208 precision float. 210 Peer Count: Defined in the MRT format [I-D.ietf-grow-mrt] 212 Peer entries: Defined in the MRT format [I-D.ietf-grow-mrt] 213 Peer Type: Defined in the MRT format [I-D.ietf-grow-mrt] 215 Peer BGP ID: Defined in the MRT format [I-D.ietf-grow-mrt] 217 Peer Latitude: Geographic latitude of the BGP peer in WGS84 [WGS-84] 218 datum decimal degrees format stored as a single precision float. 220 Peer Longitude: Geographic Longitude of the BGP peer in WGS84 221 [WGS-84] datum decimal degrees format stored as a single precision 222 float. 224 5. BGP Collector Construction 226 This section is to aide the reader in understanding the function of a 227 BGP collector. 229 The BGP Collector is a device (hardware or software based) which 230 speaks the Border Gateway Protocol and its intended function is to 231 store (and archive) the BGP routing data it receives from other BGP 232 speakers it has peering relationships with, providing data for later 233 analysis. The general nature of a BGP Collector is that it is a 234 passive device in that it listens to route updates, and does not 235 announce nor propagate any information it knows or receives. It 236 should be noted that this is not always the case, network operators 237 sometimes enable the collection of BGP routing data on active BGP 238 speakers to obtain a situational view of the routing system as they 239 see it at a particular point in time. 241 As a fully fledged BGP speaker the BGP Collector can fit into any BGP 242 topology including iBGP, eBGP, and so on. The implementation of a 243 BGP collector in a network topology is therefore limited by that 244 network's use of BGP. 246 6. Privacy Considerations 248 The GEOPRIV [RFC6280] architecture requires that privacy rules 249 attached to a location object be transmitted alongside the location 250 information in the object. If a BGP Collector adds location 251 coordinates to an MRT record based on GEOPRIV location objects, then 252 it would have to include privacy rules as well. Since the MRT geo- 253 location format does not support the the provision of privacy rules, 254 each location entry in an MRT object is assigned the following 255 default privacy rules [RFC4119]: 257 -- retransmission-allowed: True 258 -- retention-expires: 100 years from timestamp of the MRT object 259 -- ruleset-reference: Empty 260 -- note-well: Empty 262 Location information derived from a location object with more 263 restrictive privacy rules MUST NOT be included in a MRT geo-location 264 record unless there are non-technical measures in place that enforce 265 and communicate the constraints on the use of the location 266 information in the MRT geo-location format (e.g., contractual 267 agreements between peers). 269 7. Acknowledgements 271 Thanks to Andrew Clark, Ernest Foo, Dave Meyer, Larry Bluck, Richard 272 Barnes, and Jeffrey Haas for reviewing this document. 274 This document describes a small portion of the research towards the 275 author's Ph.D. 277 8. IANA Considerations 279 This section requests the Internet Assigned Numbers Authority (IANA) 280 register the additional Subtype code value as: 282 7 GEO_PEER_TABLE 284 in the "MRT format" [I-D.ietf-grow-mrt] and Subtype code values 285 related to the TABLE_DUMP_v2 type in the MRT namespace. 287 9. Security Considerations 289 This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields 290 that are of a descriptive nature and provide information that is 291 useful in the analysis of routing systems. As such, the author 292 believes that they do not constitute an additional network based 293 security risk. It is recommended that the operators of the BGP 294 collector and BGP peers consider their own privacy and security 295 concerns before supplying geographical coordinates to BGP data 296 collection systems. Special attention should be given to the 297 physical security of an organisation before supplying geographical 298 coordinates, especially if the resulting BGP data with geo-location 299 extensions is made public. 301 Entities that operate BGP Collectors, and users of data provided by 302 BGP Collectors, should be aware that the geolocation data supplied by 303 a peer can only be taken at face value. It is possible that a BGP 304 peer may supply coordinates that is purposefully misleading or 305 inaccurate. It is therefore up to the BGP Collector to include this 306 information or not, or use its own methods to either trust or 307 validate the data provided. It is not recommended that a BGP 308 Collector use geographical coordinates not supplied by a BGP peer. 310 10. References 312 10.1. Normative References 314 [I-D.ietf-grow-mrt] 315 Blunk, L., Karir, M., and C. Labovitz, "MRT routing 316 information export format", draft-ietf-grow-mrt-15 (work 317 in progress), July 2011. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, March 1997. 322 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 323 Protocol 4 (BGP-4)", RFC 4271, January 2006. 325 10.2. Informative References 327 [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", 328 August 2008, 329 . 332 [MRT-GUIDE] 333 Labovitz, C., "MRT Programmer's Guide", November 1999, 334 . 336 [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic 337 System 1984", January 2000, . 340 Author's Address 342 Terry Manderson 343 ICANN 345 Email: terry.manderson@icann.org