idnits 2.17.1 draft-manderson-sidr-geo-01.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 (June 10, 2011) is 4697 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) -- Looks like a reference, but probably isn't: '0' on line 197 == Unused Reference: 'RFC5139' is defined on line 325, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-deref-protocol-02 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-07) exists of draft-ietf-grow-geomrt-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Manderson 3 Internet-Draft ICANN 4 Intended status: Standards Track R L. Barnes 5 Expires: December 12, 2011 M. Lepinski 6 BBN 7 June 10, 2011 9 Providing first class geographical location statements for Internet 10 Number Resources 11 draft-manderson-sidr-geo-01.txt 13 Abstract 15 This document describes the construction and use of the RPKI-GEO 16 record. This record provides first class informational statements 17 pertaining to the geographical attributes of the allocated Internet 18 Number Resources. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 12, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Network Providers . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Content Providers . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Security Providers . . . . . . . . . . . . . . . . . . . . 5 59 2.4. Geo-Location (GEO) IP services . . . . . . . . . . . . . . 5 60 2.5. Research . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Required Reading . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. RPKI-GEO Structure . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. CMS Packaging . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. rPKIGEO data elements . . . . . . . . . . . . . . . . . . 8 66 4.3.1. Version . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3.2. geoLocs . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.3.3. geoObjects . . . . . . . . . . . . . . . . . . . . . . 8 69 4.3.4. inrObjects . . . . . . . . . . . . . . . . . . . . . . 9 70 4.3.5. IPAddressFam . . . . . . . . . . . . . . . . . . . . . 9 71 5. RPKI-GEO Validation . . . . . . . . . . . . . . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Requirements Notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Introduction 88 The existence of this object comes from a desire from a number of 89 Internet networking entities to use geographical awareness in 90 designing, operating, and maintaining networks. These desires are 91 briefly described here. There are of course many other efforts 92 external to the IETF and won't be described here. Further awareness 93 of these efforts is left to the reader. 95 This document describes the construction, use, and interpretation of 96 the RPKI-GEO record. This record provides first class informational 97 attestations pertaining to the geographical attributes relating to 98 the Internet Number Resources (INRs) as published by the holder of 99 the resources. The use of the geographical data is of an 100 informational nature and provides a consistent and validatable 101 approach to asserting the location properties of allocated resources. 102 To maintain consistency implementers and readers should consider the 103 9 rules in section 3 of [RFC5491]. 105 The geographic attestations made in this object are made by the 106 certificate maintainer and their validity and accuracy is in the 107 hands of the certificate maintainer. It is left to the relying party 108 as how much trust is given to the geographic data provided by the 109 certificate maintainer. 111 2.1. Network Providers 113 Customer focused network providers can use this object to 114 categorically describe the geographical attributes of customer 115 networks that will allow content providers (individually or via GEO 116 IP services) to more accurately direct customer traffic. The 117 benefits of this can be more consistent service provision, or 118 improved traffic flows in both latency and content models. 120 Anycast operations [RFC4786] might also benefit from the provision of 121 geographic information in this form. Publishing a consistent 122 awareness of the location of anycasted service nodes may help network 123 operators improve their network designs. 125 2.2. Content Providers 127 A number of content providers use the awareness they have regarding 128 the location of IP addresses to reduce the latency of provision and 129 to selectively provide content to particular locations. If a network 130 provider publishes geographic information in they will allow content 131 providers to more easily direct users traffic to their closest 132 provision point. 134 2.3. Security Providers 136 Computer emergency response teams (CERTs) and law enforcement 137 agencies (LEAs) are often concerned with where a network exists as 138 this often predicates the efforts required to address concerns of a 139 security nature given jurisdictional borders. For CERTs, this 140 knowledge is helpful for identifying an appropriate regional contact 141 for assistance when investigating computer system compromise, as well 142 as for statistical analysis purposes (for example, to geographically 143 map the incidence of occurrence over time). For law enforcement 144 purposes, attribution of network activity will likely have a high 145 priority. Correctness in published information will improve the 146 likelihood of successful resolution of security events. 148 2.4. Geo-Location (GEO) IP services 150 At present GEO IP service providers glean IP location information 151 from many sources. Its accuracy is always subject to the 152 authoritativeness of the source in addition to the specificity of the 153 provided information. GEOIP providers often have content providers 154 and Security Providers as users of their information, therefore 155 correctness of information is far reaching. 157 2.5. Research 159 There is a constant and ongoing effort to investigate and analyse the 160 global internet routing system from many different perspectives. One 161 perspective is related to the geographical position of BGP [RFC4271] 162 speakers and the terrestrial location of the route propagation. 163 Recording of such information by passive BGP listeners in MRT format 164 is described in the MRT BGP routing information export format with 165 geo-location extensions [I-D.ietf-grow-geomrt]. If this information 166 is provided in the RPKI, close approximation of location can be used 167 to model anomalous and unintended routing events in geospatial terms. 169 3. Required Reading 171 The assumption is made that the reader comprehends the RPKI, the RPKI 172 Repository Structure, and the various RPKI objects described in the 173 following: [I-D.ietf-sidr-arch], [I-D.ietf-sidr-res-certs], 174 [I-D.ietf-sidr-signed-object]. 176 4. RPKI-GEO Structure 178 The structure of the RPKI-GEO object follows the description and the 179 generic RPKI validation as described in Signed Object Template for 180 the Resource Public Key Infrastructure [I-D.ietf-sidr-signed-object] 182 4.1. CMS Packaging 184 The eContentType of the RPKI-GEO object in the encapContentInfo 185 (signed content) section of object is defined as rRPKIGEO with the 186 numerical value of [TO BE ASSIGNED]. 188 4.2. eContent 190 The content of a RPKI-GEO object identifies a set of Internet Number 191 Resources and the HELD Identity [RFC6155] or HELD Dereference 192 [I-D.ietf-geopriv-deref-protocol] URI pertaining to the INRs. 194 The ASN.1 for the RPKI-GEO object is as follows: 196 rPKIGEO ::= SEQUENCE { 197 Version [0] INTEGER DEFAULT 0, 198 geoLocs SEQUENCE (SIZE(1..MAX)) OF geoObjects 199 } 201 geoObjects ::= SEQUENCE { 202 inrSET SEQUENCE (SIZE(1..MAX)) OF inrObjects, 203 heldURI UTF8String, 204 heldTYPE BOOLEAN DEFAULT 0, 205 } 207 inrObjects ::= SEQUENCE { 208 asIDs SEQUENCE (SIZE(0..MAX)) OF ASID, 209 ipAddrBlocks SEQUENCE (SIZE(0..MAX)) OF IPAddressFam 210 } 212 IPAddressFam ::= SEQUENCE { 213 addressFam OCTET STRING (SIZE (2..3)), 214 addresses SEQUENCE (SIZE (1..MAX)) OF IPAddress 215 } 217 IPAddress ::= SEQUENCE { 218 address IPAddress, 219 length INTEGER 220 } 222 ASID ::= INTEGER 224 IPAddress ::= BIT STRING 226 } 228 4.3. rPKIGEO data elements 230 4.3.1. Version 232 The version number of this version of the rPKIGEO object MUST be 0. 234 4.3.2. geoLocs 236 This field is a sequence of geoObjects. 238 4.3.3. geoObjects 240 Each geoObject contains a sequence (inrSET) of inrObjects, a heldURI, 241 and a heldTYPE. The heldURI is a URI to either a HELD identity or 242 HELD dereference. The boolean heldTYPE specifies the HELD service 243 choice, 0 for identity and 1 for dereference. 245 4.3.4. inrObjects 247 Each inrObjects contains a sequence (asIDs) of ASID, and a sequence 248 (ipAddrBlocks) of IPAddressfam. the minimum number of both sequences 249 is zero (0) to allow the maintainer of the object to specify only AS 250 numbers or only IP address blocks, or both. 252 4.3.5. IPAddressFam 254 The IPAddressFam contains the Address Family Identifier (AFI) of an 255 IP address family in addressFam as 0001 for IPv4 and 0002 for IPv6. 256 Only IPv4 and IPv6 is supported. The sequence 'addresses' contains 257 the IP prefixes. 259 5. RPKI-GEO Validation 261 After the generic signed objects validation 262 [I-D.ietf-sidr-signed-object] has been performed, the Version number 263 field within the payload is checked. The payload data is checked 264 against the profile defined in this document. All of these checks 265 MUST pass for the RPKI-GEO payload to be considered valid and made 266 available for use. 268 6. IANA Considerations 270 This document requests IANA to add the .geo extension to the RPKI 271 file extension namespace. 273 7. Security Considerations 275 The RPKI object described here is used in a descriptive nature and 276 provides information that is useful in the analysis and design of 277 routing systems. As such, the authors believe that it does not 278 constitute an additional security risk. It is recommended that the 279 issuers of the RPKI-GEO objects consider their own privacy and 280 physical securiy concerns before supplying geographical coordinates 281 through the RPKI. 283 8. Acknowledgments 285 The authors would like to thank a number of people who have reviewed 286 this document and have provided helpful input or guidance. They are 287 Jason Smith (CERT Australia), Joel Hatton (AusCERT), Jason Ketola 288 (Maxmind), Matthew Moyle-Croft (Internode), Ernest Foo (QUT ISI), 289 George Mohay (QUT ISI), and David Graham (QLD Police). Some folks 290 who put effort into reviewing this document chose to remain 291 anonymous. Our thanks and appreciation goes to those people. 293 9. References 295 9.1. Normative References 297 [I-D.ietf-geopriv-deref-protocol] 298 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 299 Thomson, M., and M. Dawson, "A Location Dereferencing 300 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-02 301 (work in progress), December 2010. 303 [I-D.ietf-sidr-arch] 304 Lepinski, M. and S. Kent, "An Infrastructure to Support 305 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 306 progress), May 2011. 308 [I-D.ietf-sidr-res-certs] 309 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 310 X.509 PKIX Resource Certificates", 311 draft-ietf-sidr-res-certs-22 (work in progress), May 2011. 313 [I-D.ietf-sidr-signed-object] 314 Lepinski, M., Chi, A., and S. Kent, "Signed Object 315 Template for the Resource Public Key Infrastructure", 316 draft-ietf-sidr-signed-object-04 (work in progress), 317 May 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 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 326 Format for Presence Information Data Format Location 327 Object (PIDF-LO)", RFC 5139, February 2008. 329 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 330 Presence Information Data Format Location Object (PIDF-LO) 331 Usage Clarification, Considerations, and Recommendations", 332 RFC 5491, March 2009. 334 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 335 Barnes, "Use of Device Identity in HTTP-Enabled Location 336 Delivery (HELD)", RFC 6155, March 2011. 338 9.2. Informative References 340 [I-D.ietf-grow-geomrt] 341 Manderson, T., "MRT BGP routing information export format 342 with geo-location extensions", draft-ietf-grow-geomrt-02 343 (work in progress), May 2011. 345 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 346 Services", BCP 126, RFC 4786, December 2006. 348 Authors' Addresses 350 Terry Manderson 351 ICANN 353 Email: terry.manderson@icann.org 355 Richard L. Barnes 356 BBN 358 Email: rbarnes@bbn.com 360 Matt Lepinski 361 BBN 363 Email: mlepinski@bbn.com