--- 1/draft-ietf-grow-geomrt-04.txt 2011-08-17 04:17:23.000000000 +0200 +++ 2/draft-ietf-grow-geomrt-05.txt 2011-08-17 04:17:23.000000000 +0200 @@ -1,19 +1,19 @@ Global Routing Operations Working Group T. Manderson Internet-Draft ICANN -Intended status: Standards Track August 12, 2011 -Expires: February 13, 2012 +Intended status: Standards Track August 17, 2011 +Expires: February 18, 2012 Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions - draft-ietf-grow-geomrt-04.txt + draft-ietf-grow-geomrt-05.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 @@ -23,21 +23,21 @@ 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 13, 2012. + This Internet-Draft will expire on February 18, 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 @@ -49,27 +49,28 @@ Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Geo-location aware MRT Routing Information Subtype . . . . . . 6 4.1. GEO_PEER_TABLE . . . . . . . . . . . . . . . . . . . . . . 6 4.2. GEO_PEER_TABLE and peer entry values. . . . . . . . . . . 7 5. BGP Collector Construction . . . . . . . . . . . . . . . . . . 9 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 @@ -235,39 +236,62 @@ 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. Acknowledgements +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 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. -7. IANA Considerations +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. -8. Security Considerations +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 @@ -276,36 +300,36 @@ 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. -9. References +10. References -9.1. Normative References +10.1. Normative References [I-D.ietf-grow-mrt] Blunk, L., Karir, M., and C. Labovitz, "MRT routing information export format", draft-ietf-grow-mrt-15 (work in progress), July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. -9.2. Informative References +10.2. Informative References [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", August 2008, . [MRT-GUIDE] Labovitz, C., "MRT Programmer's Guide", November 1999, .