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]