Network Working Group T. Manderson Internet-Draft ICANN Intended status: Standards Track R L. Barnes Expires: December 12, 2011 M. Lepinski BBN June 10, 2011 Providing first class geographical location statements for Internet Number Resources draft-manderson-sidr-geo-01.txt Abstract This document describes the construction and use of the RPKI-GEO record. This record provides first class informational statements pertaining to the geographical attributes of the allocated Internet Number Resources. 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 December 12, 2011. 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 Manderson, et al. Expires December 12, 2011 [Page 1] Internet-Draft Geo-Location information for RPKI June 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Network Providers . . . . . . . . . . . . . . . . . . . . 4 2.2. Content Providers . . . . . . . . . . . . . . . . . . . . 4 2.3. Security Providers . . . . . . . . . . . . . . . . . . . . 5 2.4. Geo-Location (GEO) IP services . . . . . . . . . . . . . . 5 2.5. Research . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Required Reading . . . . . . . . . . . . . . . . . . . . . . . 6 4. RPKI-GEO Structure . . . . . . . . . . . . . . . . . . . . . . 7 4.1. CMS Packaging . . . . . . . . . . . . . . . . . . . . . . 7 4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. rPKIGEO data elements . . . . . . . . . . . . . . . . . . 8 4.3.1. Version . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. geoLocs . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.3. geoObjects . . . . . . . . . . . . . . . . . . . . . . 8 4.3.4. inrObjects . . . . . . . . . . . . . . . . . . . . . . 9 4.3.5. IPAddressFam . . . . . . . . . . . . . . . . . . . . . 9 5. RPKI-GEO Validation . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Manderson, et al. Expires December 12, 2011 [Page 2] Internet-Draft Geo-Location information for RPKI June 2011 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]. Manderson, et al. Expires December 12, 2011 [Page 3] Internet-Draft Geo-Location information for RPKI June 2011 2. Introduction The existence of this object comes from a desire from a number of Internet networking entities to use geographical awareness in designing, operating, and maintaining networks. These desires are briefly described here. There are of course many other efforts external to the IETF and won't be described here. Further awareness of these efforts is left to the reader. This document describes the construction, use, and interpretation of the RPKI-GEO record. This record provides first class informational attestations pertaining to the geographical attributes relating to the Internet Number Resources (INRs) as published by the holder of the resources. The use of the geographical data is of an informational nature and provides a consistent and validatable approach to asserting the location properties of allocated resources. To maintain consistency implementers and readers should consider the 9 rules in section 3 of [RFC5491]. The geographic attestations made in this object are made by the certificate maintainer and their validity and accuracy is in the hands of the certificate maintainer. It is left to the relying party as how much trust is given to the geographic data provided by the certificate maintainer. 2.1. Network Providers Customer focused network providers can use this object to categorically describe the geographical attributes of customer networks that will allow content providers (individually or via GEO IP services) to more accurately direct customer traffic. The benefits of this can be more consistent service provision, or improved traffic flows in both latency and content models. Anycast operations [RFC4786] might also benefit from the provision of geographic information in this form. Publishing a consistent awareness of the location of anycasted service nodes may help network operators improve their network designs. 2.2. Content Providers A number of content providers use the awareness they have regarding the location of IP addresses to reduce the latency of provision and to selectively provide content to particular locations. If a network provider publishes geographic information in they will allow content providers to more easily direct users traffic to their closest provision point. Manderson, et al. Expires December 12, 2011 [Page 4] Internet-Draft Geo-Location information for RPKI June 2011 2.3. Security Providers Computer emergency response teams (CERTs) and law enforcement agencies (LEAs) are often concerned with where a network exists as this often predicates the efforts required to address concerns of a security nature given jurisdictional borders. For CERTs, this knowledge is helpful for identifying an appropriate regional contact for assistance when investigating computer system compromise, as well as for statistical analysis purposes (for example, to geographically map the incidence of occurrence over time). For law enforcement purposes, attribution of network activity will likely have a high priority. Correctness in published information will improve the likelihood of successful resolution of security events. 2.4. Geo-Location (GEO) IP services At present GEO IP service providers glean IP location information from many sources. Its accuracy is always subject to the authoritativeness of the source in addition to the specificity of the provided information. GEOIP providers often have content providers and Security Providers as users of their information, therefore correctness of information is far reaching. 2.5. Research There is a constant and ongoing effort to investigate and analyse the global internet routing system from many different perspectives. One perspective is related to the geographical position of BGP [RFC4271] speakers and the terrestrial location of the route propagation. Recording of such information by passive BGP listeners in MRT format is described in the MRT BGP routing information export format with geo-location extensions [I-D.ietf-grow-geomrt]. If this information is provided in the RPKI, close approximation of location can be used to model anomalous and unintended routing events in geospatial terms. Manderson, et al. Expires December 12, 2011 [Page 5] Internet-Draft Geo-Location information for RPKI June 2011 3. Required Reading The assumption is made that the reader comprehends the RPKI, the RPKI Repository Structure, and the various RPKI objects described in the following: [I-D.ietf-sidr-arch], [I-D.ietf-sidr-res-certs], [I-D.ietf-sidr-signed-object]. Manderson, et al. Expires December 12, 2011 [Page 6] Internet-Draft Geo-Location information for RPKI June 2011 4. RPKI-GEO Structure The structure of the RPKI-GEO object follows the description and the generic RPKI validation as described in Signed Object Template for the Resource Public Key Infrastructure [I-D.ietf-sidr-signed-object] 4.1. CMS Packaging The eContentType of the RPKI-GEO object in the encapContentInfo (signed content) section of object is defined as rRPKIGEO with the numerical value of [TO BE ASSIGNED]. 4.2. eContent The content of a RPKI-GEO object identifies a set of Internet Number Resources and the HELD Identity [RFC6155] or HELD Dereference [I-D.ietf-geopriv-deref-protocol] URI pertaining to the INRs. The ASN.1 for the RPKI-GEO object is as follows: Manderson, et al. Expires December 12, 2011 [Page 7] Internet-Draft Geo-Location information for RPKI June 2011 rPKIGEO ::= SEQUENCE { Version [0] INTEGER DEFAULT 0, geoLocs SEQUENCE (SIZE(1..MAX)) OF geoObjects } geoObjects ::= SEQUENCE { inrSET SEQUENCE (SIZE(1..MAX)) OF inrObjects, heldURI UTF8String, heldTYPE BOOLEAN DEFAULT 0, } inrObjects ::= SEQUENCE { asIDs SEQUENCE (SIZE(0..MAX)) OF ASID, ipAddrBlocks SEQUENCE (SIZE(0..MAX)) OF IPAddressFam } IPAddressFam ::= SEQUENCE { addressFam OCTET STRING (SIZE (2..3)), addresses SEQUENCE (SIZE (1..MAX)) OF IPAddress } IPAddress ::= SEQUENCE { address IPAddress, length INTEGER } ASID ::= INTEGER IPAddress ::= BIT STRING } 4.3. rPKIGEO data elements 4.3.1. Version The version number of this version of the rPKIGEO object MUST be 0. 4.3.2. geoLocs This field is a sequence of geoObjects. 4.3.3. geoObjects Each geoObject contains a sequence (inrSET) of inrObjects, a heldURI, and a heldTYPE. The heldURI is a URI to either a HELD identity or Manderson, et al. Expires December 12, 2011 [Page 8] Internet-Draft Geo-Location information for RPKI June 2011 HELD dereference. The boolean heldTYPE specifies the HELD service choice, 0 for identity and 1 for dereference. 4.3.4. inrObjects Each inrObjects contains a sequence (asIDs) of ASID, and a sequence (ipAddrBlocks) of IPAddressfam. the minimum number of both sequences is zero (0) to allow the maintainer of the object to specify only AS numbers or only IP address blocks, or both. 4.3.5. IPAddressFam The IPAddressFam contains the Address Family Identifier (AFI) of an IP address family in addressFam as 0001 for IPv4 and 0002 for IPv6. Only IPv4 and IPv6 is supported. The sequence 'addresses' contains the IP prefixes. Manderson, et al. Expires December 12, 2011 [Page 9] Internet-Draft Geo-Location information for RPKI June 2011 5. RPKI-GEO Validation After the generic signed objects validation [I-D.ietf-sidr-signed-object] has been performed, the Version number field within the payload is checked. The payload data is checked against the profile defined in this document. All of these checks MUST pass for the RPKI-GEO payload to be considered valid and made available for use. Manderson, et al. Expires December 12, 2011 [Page 10] Internet-Draft Geo-Location information for RPKI June 2011 6. IANA Considerations This document requests IANA to add the .geo extension to the RPKI file extension namespace. Manderson, et al. Expires December 12, 2011 [Page 11] Internet-Draft Geo-Location information for RPKI June 2011 7. Security Considerations The RPKI object described here is used in a descriptive nature and provides information that is useful in the analysis and design of routing systems. As such, the authors believe that it does not constitute an additional security risk. It is recommended that the issuers of the RPKI-GEO objects consider their own privacy and physical securiy concerns before supplying geographical coordinates through the RPKI. Manderson, et al. Expires December 12, 2011 [Page 12] Internet-Draft Geo-Location information for RPKI June 2011 8. Acknowledgments The authors would like to thank a number of people who have reviewed this document and have provided helpful input or guidance. They are Jason Smith (CERT Australia), Joel Hatton (AusCERT), Jason Ketola (Maxmind), Matthew Moyle-Croft (Internode), Ernest Foo (QUT ISI), George Mohay (QUT ISI), and David Graham (QLD Police). Some folks who put effort into reviewing this document chose to remain anonymous. Our thanks and appreciation goes to those people. Manderson, et al. Expires December 12, 2011 [Page 13] Internet-Draft Geo-Location information for RPKI June 2011 9. References 9.1. Normative References [I-D.ietf-geopriv-deref-protocol] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., and M. Dawson, "A Location Dereferencing Protocol Using HELD", draft-ietf-geopriv-deref-protocol-02 (work in progress), December 2010. [I-D.ietf-sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-13 (work in progress), May 2011. [I-D.ietf-sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-22 (work in progress), May 2011. [I-D.ietf-sidr-signed-object] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure", draft-ietf-sidr-signed-object-04 (work in progress), May 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. [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008. [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009. [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011. Manderson, et al. Expires December 12, 2011 [Page 14] Internet-Draft Geo-Location information for RPKI June 2011 9.2. Informative References [I-D.ietf-grow-geomrt] Manderson, T., "MRT BGP routing information export format with geo-location extensions", draft-ietf-grow-geomrt-02 (work in progress), May 2011. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006. Manderson, et al. Expires December 12, 2011 [Page 15] Internet-Draft Geo-Location information for RPKI June 2011 Authors' Addresses Terry Manderson ICANN Email: terry.manderson@icann.org Richard L. Barnes BBN Email: rbarnes@bbn.com Matt Lepinski BBN Email: mlepinski@bbn.com Manderson, et al. Expires December 12, 2011 [Page 16]