Providing first class geographical location statements for RPKI objects
draft-manderson-sidr-geo-00.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 information described in RPKI objects.

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 August 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Requirements Notation
• 2. Introduction
• 3. Suggested Reading
• 4. RPKI-GEO Structure
• 4.1. CMS Packaging
• 4.2. eContent
• 4.3. RPKI-GEO data elements
• 4.3.1. Version
• 4.3.2. geoLocs
• 4.3.3. FileAndHash
• 4.3.4. geoXML
• 4.3.4.1. Type 0
• 4.3.4.2. Type 1
• 5. RPKI-GEO Validation
• 6. RPKI-GEO interpretation
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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

There is a constant an 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]. 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 information described in RPKI objects. The use of the geographical data is of an informational nature and provides a consistent and validatable approach to asserting the location properties of any item described by an RPKI object. To maintain consistency implementers and readers should condier the 9 rules in section 3 of [RFC5491].

It is not intended that the RPKI object described herein be used to directly influence routing or forwarding decisions. Its creation by any certificate maintainer is to be interpreted as informational and any replying party should only use the knowledge in the efforts of routing research or anomaly detection.

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.

The RPKI-GEO object pertains only to the objects at the same RPKI repository publication point where it itself is published.

3. Suggested 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], [I-D.ietf-sidr-roa-format], [I-D.ietf-sidr-rpki-manifests], [I-D.ietf-sidr-ghostbusters].

4. RPKI-GEO Structure

The structure of the GEO-RPKI 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 rpkiGEO with the numerical value of TO BE ASSIGNED.

4.2. eContent

The content of a RPKI-GEO object identifies an RPKI object and the geographical coordinates associated with the item described by the RPKI object.

The ASN.1 for the RPKI-GEO object is as follows:

		
rPKIGEO ::= SEQUENCE {
	Version       [0] INTEGER DEFAULT 0,
	geoLocs SEQUENCE (SIZE(1..MAX)) OF geoOBJECTS 
	}

geoObjects ::= SEQUENCE {
    objectFile		FileAndHash,
    geoAttribs		SEQUENCE (SIZE(1..MAX)) OF geoXML
    }		
    
FileAndHash ::=     SEQUENCE {
    file            IA5String,
    hash            BIT STRING
    }
    
geoXML ::= SEQUENCE {
   type   INTEGER DEFAULT 0,
   xmlDoc PrintableString
}

		

4.3. RPKI-GEO data elements

4.3.1. Version

The version number of this version of the GEO-RPKI object MUST be 0.

4.3.2. geoLocs

This field is a sequence of geoObjects. Each geoObject contains a FileAndHash element and a sequence of geoXML. The geoLoc object MUST contain at least one geoXML object of type 0 for each FileAndHash element

4.3.3. FileAndHash

The single FileAndHash entry in each geoObject corresponds to each currently valid signed object that has been published by the authority (at this publication point). The description is as seen in [I-D.ietf-sidr-rpki-manifests]: Each FileAndHash is an ordered pair consisting of the name of the file in the repository publication point that contains the object in question, and a hash of the file's contents.

The publication point manifest and RPKI-GEO object's FileAndHash MUST NOT appear in a RPKI-GEO object.

4.3.4. geoXML

The geoXML contains the details of the geographical location information in an xml representation defined by the geoXML type value. The type specifies the XML schema used in the xmlDoc portion. There are 2 valid types.

	Type 0:	A GML syntax
	Type 1: A Civic Address Syntax
	

4.3.4.1. Type 0

Type 0 is a constrained GML syntax [GML]. The constraints on the syntax are as follows.

Coordinate datum selection: The coordinates used in the GML will use the WGS84 datum [WGS84]. Any use of another datum specified in the GML in this object is considered illegal. This is for compatibility and uniformity.

The XML contained on the xmlDoc geoXML element for type = 0 MUST contain only one GML reference of either point or polygon representations.

<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
  <gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point>

		

4.3.4.2. Type 1

A Type 1 xmlDoc contains a Civic address representation of the location information and is defined in [RFC5139].

   <civicAddress xml:lang="en-AU"
     xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
     <country>AU</country>
     <A1>NSW</A1>
     <A3>     Wollongong
     </A3><A4>North Wollongong
     </A4>
     <RD>Flinders</RD><STS>Street</STS>
     <RDBR>Campbell Street</RDBR>
     <LMK>
       Gilligan's Island
     </LMK> <LOC>Corner</LOC>
     <NAM> Video Rental Store </NAM>
     <PC>2500</PC>
     <ROOM> Westerns and Classics </ROOM>
     <PLC>store</PLC>
     <POBOX>Private Box 15</POBOX>
   </civicAddress>

		

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.

6. RPKI-GEO interpretation

A common sense interpretation of location data should prevail based on the type of the data that is represented in the RPKI object. For example a RPKI-GEO object that provides location information for a ROA would attest to the geographical location where the route is originated from. That may be the originating BGP speaker(s) as described in [I-D.ietf-grow-geomrt]. Similarly the location information associated with a Ghostbusters record [I-D.ietf-sidr-ghostbusters] would describe the geographical location of the entity described in the Ghostbusters VCARD.

7. IANA Considerations

This document requests IANA to add the .geo extention to the RPKI file extension namespace.

8. Security Considerations

The RPKI object described here is used in a descriptive nature and provide information that is useful in the analysis of routing systems. As such, the authors believes that it does not constitute an additional security risk. It is recommended that the issuers of the GEO-RPKI objects consider their own privacy concerns before supplying geographical coordinates in the RPKI.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses