rfc9092.original   rfc9092.txt 
Network Working Group R. Bush Internet Engineering Task Force (IETF) R. Bush
Internet-Draft IIJ & Arrcus Request for Comments: 9092 IIJ & Arrcus
Intended status: Standards Track M. Candela Category: Standards Track M. Candela
Expires: November 26, 2021 NTT ISSN: 2070-1721 NTT
W. Kumari W. Kumari
Google Google
R. Housley R. Housley
Vigil Security Vigil Security
May 25, 2021 July 2021
Finding and Using Geofeed Data Finding and Using Geofeed Data
draft-ietf-opsawg-finding-geofeeds-17
Abstract Abstract
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language inetnum: class to refer specifically to Specification Language inetnum: class to refer specifically to
geofeed data CSV files, and describes an optional scheme to use the geofeed data comma-separated values (CSV) files and describes an
Routing Public Key Infrastructure to authenticate the geofeed data optional scheme that uses the Routing Public Key Infrastructure to
CSV files. authenticate the geofeed data CSV files.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on November 26, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9092.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Geofeed Files
3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3 3. inetnum: Class
4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 5 4. Authenticating Geofeed Data
5. Operational Considerations . . . . . . . . . . . . . . . . . 8 5. Operational Considerations
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 6. Privacy Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Example
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses
1. Introduction 1. Introduction
Providers of Internet content and other services may wish to Providers of Internet content and other services may wish to
customize those services based on the geographic location of the user customize those services based on the geographic location of the user
of the service. This is often done using the source IP address used of the service. This is often done using the source IP address used
to contact the service. Also, infrastructure and other services to contact the service. Also, infrastructure and other services
might wish to publish the locale of their services. [RFC8805] might wish to publish the locale of their services. [RFC8805]
defines geofeed, a syntax to associate geographic locales with IP defines geofeed, a syntax to associate geographic locales with IP
addresses. But it does not specify how to find the relevant geofeed addresses, but it does not specify how to find the relevant geofeed
data given an IP address. data given an IP address.
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language (RPSL) [RFC2725] inetnum: class to refer Specification Language (RPSL) [RFC2725] inetnum: class to refer
specifically to geofeed data CSV files, and how to prudently use specifically to geofeed data CSV files and how to prudently use them.
them. In all places inetnum: is used, inet6num: should also be In all places inetnum: is used, inet6num: should also be assumed
assumed [RFC4012]. [RFC4012].
The reader may find [INETNUM] and [INET6NUM] informative, and The reader may find [INETNUM] and [INET6NUM] informative, and
certainly more verbose, descriptions of the inetnum: database certainly more verbose, descriptions of the inetnum: database
classes. classes.
An optional, utterly awesome but slightly complex means for An optional utterly awesome but slightly complex means for
authenticating geofeed data is also defined. authenticating geofeed data is also defined.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Geofeed Files 2. Geofeed Files
Geofeed files are described in [RFC8805]. They provide a facility Geofeed files are described in [RFC8805]. They provide a facility
for an IP address resource 'owner' to associate those IP addresses to for an IP address resource "owner" to associate those IP addresses to
geographic locales. geographic locales.
Content providers and other parties who wish to locate an IP address Content providers and other parties who wish to locate an IP address
to a geographic locale need to find the relevant geofeed data. In to a geographic locale need to find the relevant geofeed data. In
Section 3, this document specifies how to find the relevant [RFC8805] Section 3, this document specifies how to find the relevant geofeed
geofeed file given an IP address. [RFC8805] file given an IP address.
Geofeed data for large providers with significant horizontal scale Geofeed data for large providers with significant horizontal scale
and high granularity can be quite large. The size of a file can be and high granularity can be quite large. The size of a file can be
even larger if an unsigned geofeed file combines data for many even larger if an unsigned geofeed file combines data for many
prefixes, dual IPv4/IPv6 spaces are represented, etc. prefixes, if dual IPv4/IPv6 spaces are represented, etc.
Geofeed data do have privacy considerations, see Section 6; and this Geofeed data do have privacy considerations (see Section 6); this
process makes bulk access to those data easier. process makes bulk access to those data easier.
This document also suggests an optional signature to strongly This document also suggests an optional signature to strongly
authenticate the data in the geofeed files. authenticate the data in the geofeed files.
3. inetnum: Class 3. inetnum: Class
The original RPSL specifications starting with [RIPE81], [RIPE181], The original RPSL specifications starting with [RIPE81], [RIPE181],
and a trail of subsequent documents were done by the RIPE community. and a trail of subsequent documents were written by the RIPE
The IETF standardized RPSL in [RFC2622] and [RFC4012]. Since then, community. The IETF standardized RPSL in [RFC2622] and [RFC4012].
it has been modified and extensively enhanced in the Regional Since then, it has been modified and extensively enhanced in the
Internet Registry (RIR) community, mostly by RIPE, [RIPE-DB]. Regional Internet Registry (RIR) community, mostly by RIPE [RIPE-DB].
Currently, change control effectively lies in the operator community. Currently, change control effectively lies in the operator community.
The Routing Policy Specification Language (RPSL), and [RFC2725] and The RPSL, and [RFC2725] and [RFC4012] used by the Regional Internet
[RFC4012] used by the Regional Internet Registries (RIRs) specifies Registries (RIRs), specify the inetnum: database class. Each of
the inetnum: database class. Each of these objects describes an IP these objects describes an IP address range and its attributes. The
address range and its attributes. The inetnum: objects form a inetnum: objects form a hierarchy ordered on the address space.
hierarchy ordered on the address space.
Ideally, RPSL would be augmented to define a new RPSL geofeed: Ideally, RPSL would be augmented to define a new RPSL geofeed:
attribute in the inetnum: class. Until such time, this document attribute in the inetnum: class. Until such time, this document
defines the syntax of a Geofeed remarks: attribute which contains an defines the syntax of a Geofeed remarks: attribute, which contains an
HTTPS URL of a geofeed file. The format of the inetnum: geofeed HTTPS URL of a geofeed file. The format of the inetnum: geofeed
remarks: attribute MUST be as in this example, "remarks: Geofeed ", remarks: attribute MUST be as in this example, "remarks: Geofeed ",
where the token "Geofeed" MUST be case-sensitive, followed by a URL where the token "Geofeed " MUST be case sensitive, followed by a URL
which will vary, but MUST refer only to a single [RFC8805] geofeed that will vary, but it MUST refer only to a single geofeed [RFC8805]
file. file.
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed.csv remarks: Geofeed https://example.com/geofeed.csv
While we leave global agreement of RPSL modification to the relevant While we leave global agreement of RPSL modification to the relevant
parties, we specify that a proper geofeed: attribute in the inetnum: parties, we specify that a proper geofeed: attribute in the inetnum:
class MUST be "geofeed: ", and MUST be followed by a single URL which class MUST be "geofeed:" and MUST be followed by a single URL that
will vary, but MUST refer only to a single [RFC8805] geofeed file. will vary, but it MUST refer only to a single geofeed [RFC8805] file.
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed.csv geofeed: https://example.com/geofeed.csv
Registries MAY, for the interim, provide a mix of the remarks: Registries MAY, for the interim, provide a mix of the remarks:
attribute form and the geofeed: attribute form. attribute form and the geofeed: attribute form.
The URL uses HTTPS, so the WebPKI provides authentication, integrity, The URL uses HTTPS, so the WebPKI provides authentication, integrity,
and confidentiality for the fetched geofeed file. However, the and confidentiality for the fetched geofeed file. However, the
WebPKI can not provide authentication of IP address space assignment. WebPKI can not provide authentication of IP address space assignment.
In contrast, the Resource Public Key Infrastructure (RPKI, see In contrast, the RPKI (see [RFC6481]) can be used to authenticate IP
[RFC6481]) can be used to authenticate IP space assignment; see space assignment; see optional authentication in Section 4.
optional authentication in Section 4.
Until all producers of inetnum:s, i.e. the RIRs, state that they have Until all producers of inetnum: objects, i.e., the RIRs, state that
migrated to supporting a geofeed: attribute, consumers looking at they have migrated to supporting a geofeed: attribute, consumers
inetnum:s to find geofeed URLs MUST be able to consume both the looking at inetnum: objects to find geofeed URLs MUST be able to
remarks: and geofeed: forms. The migration not only implies that the consume both the remarks: and geofeed: forms. The migration not only
RIRs support the geofeed: attribute, but that all registrants have implies that the RIRs support the geofeed: attribute, but that all
migrated any inetnum:s from remarks: use to geofeed:s. registrants have migrated any inetnum: objects from remarks: to
geofeed: attributes.
Any particular inetnum: object MUST have at most, one geofeed Any particular inetnum: object MUST have, at most, one geofeed
reference, whether a remarks: or a proper geofeed: attribute when it reference, whether a remarks: or a proper geofeed: attribute when it
is implemented. If there is more than one, all are ignored. is implemented. If there is more than one, all are ignored.
If a geofeed CSV file describes multiple disjoint ranges of IP If a geofeed CSV file describes multiple disjoint ranges of IP
address space, there are likely to be geofeed references from address space, there are likely to be geofeed references from
multiple inetnum: objects. Files with geofeed references from multiple inetnum: objects. Files with geofeed references from
multiple inetnum: objects are not compatible with the signing multiple inetnum: objects are not compatible with the signing
procedure in Section 4. procedure in Section 4.
When geofeed references are provided by multiple inetnum: objects When geofeed references are provided by multiple inetnum: objects
which have identical address ranges, then the geofeed reference on that have identical address ranges, then the geofeed reference on the
the inetnum: with the most recent last-modified: attribute SHOULD be inetnum: with the most recent last-modified: attribute SHOULD be
preferred. preferred.
As inetnum: objects form a hierarchy, Geofeed references SHOULD be at As inetnum: objects form a hierarchy, geofeed references SHOULD be at
the lowest applicable inetnum: object covering the relevant address the lowest applicable inetnum: object covering the relevant address
ranges in the referenced geofeed file. When fetching, the most ranges in the referenced geofeed file. When fetching, the most
specific inetnum: object with a geofeed reference MUST be used. specific inetnum: object with a geofeed reference MUST be used.
It is significant that geofeed data may have finer granularity than It is significant that geofeed data may have finer granularity than
the inetnum: which refers to them. For example an INETNUM object for the inetnum: that refers to them. For example, an INETNUM object for
an address range P could refer to a geofeed file in which P has been an address range P could refer to a geofeed file in which P has been
sub-divided into one or more longer prefixes. subdivided into one or more longer prefixes.
Currently, the registry data published by ARIN is not the same RPSL Currently, the registry data published by ARIN are not the same RPSL
as that of the other registries (see [RFC7485] for a survey of the as that of the other registries (see [RFC7485] for a survey of the
whois Tower of Babel); therefore, when fetching from ARIN via FTP WHOIS Tower of Babel); therefore, when fetching from ARIN via FTP
[RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the [RFC0959], WHOIS [RFC3912], the Registration Data Access Protocol
"NetRange" attribute/key MUST be treated as "inetnum" and the (RDAP) [RFC9082], etc., the "NetRange" attribute/key MUST be treated
"Comment" attribute MUST be treated as "remarks". as "inetnum", and the "Comment" attribute MUST be treated as
"remarks".
4. Authenticating Geofeed Data 4. Authenticating Geofeed Data
The question arises whether a particular [RFC8805] geofeed data set The question arises whether a particular geofeed [RFC8805] data set
is valid, i.e. is authorized by the 'owner' of the IP address space is valid, i.e., is authorized by the "owner" of the IP address space
and is authoritative in some sense. The inetnum: which points to the and is authoritative in some sense. The inetnum: that points to the
[RFC8805] geofeed file provides some assurance. Unfortunately, the geofeed [RFC8805] file provides some assurance. Unfortunately, the
RPSL in many repositories is weakly authenticated at best. An RPSL in many repositories is weakly authenticated at best. An
approach where RPSL was signed a la [RFC7909] would be good, except approach where RPSL was signed per [RFC7909] would be good, except it
it would have to be deployed by all RPSL registries, and there is a would have to be deployed by all RPSL registries, and there is a fair
fair number of them. number of them.
A single optional authenticator MAY be appended to a [RFC8805] A single optional authenticator MAY be appended to a geofeed
geofeed file. It is a digest of the main body of the file signed by [RFC8805] file. It is a digest of the main body of the file signed
the private key of the relevant RPKI certificate for a covering by the private key of the relevant RPKI certificate for a covering
address range. One needs a format that bundles the relevant RPKI address range. One needs a format that bundles the relevant RPKI
certificate with the signature of the geofeed text. certificate with the signature of the geofeed text.
The canonicalization procedure converts the data from its internal The canonicalization procedure converts the data from their internal
character representation to the UTF-8 [RFC3629] character encoding, character representation to the UTF-8 [RFC3629] character encoding,
and the <CRLF> sequence MUST be used to denote the end of a line of and the <CRLF> sequence MUST be used to denote the end of a line of
text. A blank line is represented solely by the <CRLF> sequence. text. A blank line is represented solely by the <CRLF> sequence.
For robustness, any non-printable characters MUST NOT be changed by For robustness, any non-printable characters MUST NOT be changed by
canonicalization. Trailing blank lines MUST NOT appear at the end of canonicalization. Trailing blank lines MUST NOT appear at the end of
the file. That is, the file must not end with multiple consecutive the file. That is, the file must not end with multiple consecutive
<CRLF> sequences. Any end-of-file marker used by an operating system <CRLF> sequences. Any end-of-file marker used by an operating system
is not considered to be part of the file content. When present, such is not considered to be part of the file content. When present, such
end-of-file markers MUST NOT be processed by the digital signature end-of-file markers MUST NOT be processed by the digital signature
algorithm. algorithm.
Should the authenticator be syntactically incorrect per the above, Should the authenticator be syntactically incorrect per the above,
the authenticator is invalid. the authenticator is invalid.
Borrowing detached signatures from [RFC5485], after file Borrowing detached signatures from [RFC5485], after file
canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
would be used to create a detached DER encoded signature which is would be used to create a detached DER-encoded signature that is then
then padded BASE64 encoded (as per [RFC4648] Section 4), and line padded BASE64 encoded (as per Section 4 of [RFC4648]) and line
wrapped to 72 or fewer characters. The same digest algorithm MUST be wrapped to 72 or fewer characters. The same digest algorithm MUST be
used for calculating the message digest on content being signed, used for calculating the message digest on content being signed,
which is the geofeed file, and calculating the message digest on the which is the geofeed file, and for calculating the message digest on
SignerInfo SignedAttributes [RFC8933]. The message digest algorithm the SignerInfo SignedAttributes [RFC8933]. The message digest
identifier MUST appear in both the SigenedData algorithm identifier MUST appear in both the SignedData
DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifiers and the SignerInfo
DigestAlgorithmIdentifier [RFC5652]. DigestAlgorithmIdentifier [RFC5652].
The address range of the signing certificate MUST cover all prefixes The address range of the signing certificate MUST cover all prefixes
in the geofeed file it signs. in the geofeed file it signs.
An address range A 'covers' address range B if the range of B is An address range A "covers" address range B if the range of B is
identical to or a subset of A. 'Address range' is used here because identical to or a subset of A. "Address range" is used here because
inetnum: objects and RPKI certificates need not align on CIDR prefix inetnum: objects and RPKI certificates need not align on Classless
boundaries, while those of the CSV lines in a geofeed file do. Inter-Domain Routing (CIDR) [RFC4632] prefix boundaries, while those
of the CSV lines in a geofeed file do.
As the signer specifies the covered RPKI resources relevant to the As the signer specifies the covered RPKI resources relevant to the
signature, the RPKI certificate covering the inetnum: object's signature, the RPKI certificate covering the inetnum: object's
address range is included in the [RFC5652] CMS SignedData address range is included in the [RFC5652] CMS SignedData
certificates field. certificates field.
Identifying the private key associated with the certificate, and Identifying the private key associated with the certificate and
getting the department that controls the private key (which might be getting the department that controls the private key (which might be
trapped in a Hardware Security Module, HSM) to sign the CMS blob is trapped in a Hardware Security Module (HSM)) to sign the CMS blob is
left as an exercise for the implementor. On the other hand, left as an exercise for the implementor. On the other hand,
verifying the signature requires no complexity; the certificate, verifying the signature requires no complexity; the certificate,
which can be validated in the public RPKI, has the needed public key. which can be validated in the public RPKI, has the needed public key.
The trust anchors for the RIRs are expected to already be available The trust anchors for the RIRs are expected to already be available
to the party performing signature validation. Validation of the CMS to the party performing signature validation. Validation of the CMS
signature on the geofeed file involves: signature on the geofeed file involves:
1. Obtain the signer's certificate from the CMS SignedData 1. Obtaining the signer's certificate from the CMS SignedData
CertificateSet [RFC5652]. The certificate SubjectKeyIdentifier CertificateSet [RFC5652]. The certificate SubjectKeyIdentifier
extension [RFC5280] MUST match the SubjectKeyIdentifier in the extension [RFC5280] MUST match the SubjectKeyIdentifier in the
CMS SignerInfo SignerIdentifier [RFC5652]. If the key CMS SignerInfo SignerIdentifier [RFC5652]. If the key
identifiers do not match, then validation MUST fail. identifiers do not match, then validation MUST fail.
2. Construct the certification path for the signer's certificate. Validation of the signer's certificate MUST ensure that it is
part of the current [RFC6486] manifest and that the resources are
covered by the RPKI certificate.
2. Constructing the certification path for the signer's certificate.
All of the needed certificates are expected to be readily All of the needed certificates are expected to be readily
available in the RPKI Repository. The certification path MUST be available in the RPKI repository. The certification path MUST be
valid according to the validation algorithm in [RFC5280] and the valid according to the validation algorithm in [RFC5280] and the
additional checks specified in [RFC3779] associated with the IP additional checks specified in [RFC3779] associated with the IP
Address Delegation certificate extension and the Autonomous Address Delegation certificate extension and the Autonomous
System Identifier Delegation certificate extension. If System Identifier Delegation certificate extension. If
certification path validation is unsuccessful, then validation certification path validation is unsuccessful, then validation
MUST fail. MUST fail.
3. Validate the CMS SignedData as specified in [RFC5652] using the 3. Validating the CMS SignedData as specified in [RFC5652] using the
public key from the validated signer's certificate. If the public key from the validated signer's certificate. If the
signature validation is unsuccessful, then validation MUST fail. signature validation is unsuccessful, then validation MUST fail.
4. Verify that the IP Address Delegation certificate extension 4. Verifying that the IP Address Delegation certificate extension
[RFC3779] covers all of the address ranges of the geofeed file. [RFC3779] covers all of the address ranges of the geofeed file.
If all of the address ranges are not covered, then validation If all of the address ranges are not covered, then validation
MUST fail. MUST fail.
5. Validation of the signer's certificate MUST ensure that it is
part of the current [RFC6486] manifest and that the resources are
covered by the RPKI certificate.
All of these steps MUST be successful to consider the geofeed file All of these steps MUST be successful to consider the geofeed file
signature as valid. signature as valid.
As the signer specifies the covered RPKI resources relevant to the As the signer specifies the covered RPKI resources relevant to the
signature, the RPKI certificate covering the inetnum: object's signature, the RPKI certificate covering the inetnum: object's
address range is included in the [RFC5652] CMS SignedData address range is included in the CMS SignedData certificates field
certificates field. [RFC5652].
Identifying the private key associated with the certificate, and Identifying the private key associated with the certificate and
getting the department with the Hardware Security Module (HSM) to getting the department with the Hardware Security Module (HSM) to
sign the CMS blob is left as an exercise for the implementor. On the sign the CMS blob is left as an exercise for the implementor. On the
other hand, verifying the signature requires no complexity; the other hand, verifying the signature requires no complexity; the
certificate, which can be validated in the public RPKI, has the certificate, which can be validated in the public RPKI, has the
needed public key. needed public key.
The appendix MUST be 'hidden' as a series of "#" comments at the end The appendix MUST be hidden as a series of "#" comments at the end of
of the geofeed file. The following is a cryptographically incorrect, the geofeed file. The following is a cryptographically incorrect,
albeit simple example. A correct and full example is in Appendix A. albeit simple, example. A correct and full example is in Appendix A.
# RPKI Signature: 192.0.2.0 - 192.0.2.255 # RPKI Signature: 192.0.2.0 - 192.0.2.255
# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
... ...
# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk= # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
# End Signature: 192.0.2.0 - 192.0.2.255 # End Signature: 192.0.2.0 - 192.0.2.255
The signature does not cover the signature lines. The signature does not cover the signature lines.
The bracketing "# RPKI Signature:" and "# End Signature:" MUST be The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
present following the model as shown. Their IP address range MUST present following the model as shown. Their IP address range MUST
match that of the inetnum: URL followed to the file. match that of the inetnum: URL followed to the file.
[I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a [RPKI-RSC] describes and provides code for a CMS profile for a
Cryptographic Message Syntax (CMS) profile for a general purpose general purpose listing of checksums (a "checklist") for use with the
listing of checksums (a 'checklist'), for use with the Resource Resource Public Key Infrastructure (RPKI). It provides usable,
Public Key Infrastructure (RPKI). It provides usable, albeit albeit complex, code to sign geofeed files.
complex, code to sign geofeed files.
[I-D.ietf-sidrops-rpki-rta] describes a Cryptographic Message Syntax [RPKI-RTA] describes a CMS profile for a general purpose Resource
(CMS) profile for a general purpose Resource Tagged Attestation (RTA) Tagged Attestation (RTA) based on the RPKI. While this is expected
based on the RPKI. While this is expected to become applicable in to become applicable in the long run, for the purposes of this
the long run, for the purposes of this document, a self-signed root document, a self-signed root trust anchor is used.
trust anchor is used.
5. Operational Considerations 5. Operational Considerations
To create the needed inetnum: objects, an operator wishing to To create the needed inetnum: objects, an operator wishing to
register the location of their geofeed file needs to coordinate with register the location of their geofeed file needs to coordinate with
their RIR/NIR and/or any provider LIR which has assigned address their Regional Internet Registry (RIR) or National Internet Registry
ranges to them. RIRs/NIRs provide means for assignees to create and (NIR) and/or any provider Local Internet Registry (LIR) that has
maintain inetnum: objects. They also provide means of assigned address ranges to them. RIRs/NIRs provide means for
[sub-]assigning IP address resources and allowing the assignee to assignees to create and maintain inetnum: objects. They also provide
create whois data, including inetnum: objects, and thereby referring means of assigning or sub-assigning IP address resources and allowing
to geofeed files. the assignee to create WHOIS data, including inetnum: objects,
thereby referring to geofeed files.
The geofeed files MUST be published via and fetched using HTTPS The geofeed files MUST be published via and fetched using HTTPS
[RFC2818]. [RFC2818].
When using data from a geofeed file, one MUST ignore data outside the When using data from a geofeed file, one MUST ignore data outside the
referring inetnum: object's inetnum: attribute address range. referring inetnum: object's inetnum: attribute address range.
If and only if the geofeed file is not signed per Section 4, then If and only if the geofeed file is not signed per Section 4, then
multiple inetnum: objects MAY refer to the same geofeed file, and the multiple inetnum: objects MAY refer to the same geofeed file, and the
consumer MUST use only lines in the geofeed file where the prefix is consumer MUST use only lines in the geofeed file where the prefix is
covered by the address range of the inetnum: object's URL it has covered by the address range of the inetnum: object's URL it has
followed. followed.
If the geofeed file is signed, and the signer's certificate changes, If the geofeed file is signed, and the signer's certificate changes,
the signature in the geofeed file MUST be updated. the signature in the geofeed file MUST be updated.
It is good key hygiene to use a given key for only one purpose. To It is good key hygiene to use a given key for only one purpose. To
dedicate a signing private key for signing a geofeed file, an RPKI CA dedicate a signing private key for signing a geofeed file, an RPKI
may issue a subordinate certificate exclusively for the purpose as Certification Authority (CA) may issue a subordinate certificate
shown in Appendix A. exclusively for the purpose shown in Appendix A.
To minimize the load on RIR whois [RFC3912] services, use of the To minimize the load on RIR WHOIS [RFC3912] services, use of the
RIR's FTP [RFC0959] services SHOULD be used for large scale access to RIR's FTP [RFC0959] services SHOULD be used for large-scale access to
gather geofeed URLs. This also provides bulk access instead of gather geofeed URLs. This also provides bulk access instead of
fetching by brute force search through the IP space. fetching by brute-force search through the IP space.
Currently, geolocation providers have bulk whois data access at all Currently, geolocation providers have bulk WHOIS data access at all
the RIRs. An anonymized version of such data is openly available for the RIRs. An anonymized version of such data is openly available for
all RIRs except ARIN, which requires an authorization. However, for all RIRs except ARIN, which requires an authorization. However, for
users without such authorization, the same result can be achieved users without such authorization, the same result can be achieved
with extra RDAP effort. There is open source code to pass over such with extra RDAP effort. There is open-source code to pass over such
data across all RIRs, collect all geofeed references, and process data across all RIRs, collect all geofeed references, and process
them [geofeed-finder]. them [GEOFEED-FINDER].
To prevent undue load on RPSL and geofeed servers, an entity fetching To prevent undue load on RPSL and geofeed servers, entity-fetching
geofeed data using these mechanisms MUST NOT do frequent real-time geofeed data using these mechanisms MUST NOT do frequent real-time
look-ups. [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP lookups. Section 3.4 of [RFC8805] suggests use of the HTTP Expires
Expires Caching Header to signal when geofeed data should be header [RFC7234] to signal when geofeed data should be refetched. As
refetched. As the data change very infrequently, in the absence of the data change very infrequently, in the absence of such an HTTP
such an HTTP Header signal, collectors SHOULD NOT fetch more Header signal, collectors SHOULD NOT fetch more frequently than
frequently than weekly. It would be polite not to fetch at magic weekly. It would be polite not to fetch at magic times such as
times such as midnight UTC, the first of the month, etc., because too midnight UTC, the first of the month, etc., because too many others
many others are likely to do the same. are likely to do the same.
6. Privacy Considerations 6. Privacy Considerations
[RFC8805] geofeed data may reveal the approximate location of an IP [RFC8805] geofeed data may reveal the approximate location of an IP
address, which might in turn reveal the approximate location of an address, which might in turn reveal the approximate location of an
individual user. Unfortunately, [RFC8805] provides no privacy individual user. Unfortunately, [RFC8805] provides no privacy
guidance on avoiding or ameliorating possible damage due to this guidance on avoiding or ameliorating possible damage due to this
exposure of the user. In publishing pointers to geofeed files as exposure of the user. In publishing pointers to geofeed files as
described in this document, the operator should be aware of this described in this document, the operator should be aware of this
exposure in geofeed data and be cautious. All the privacy exposure in geofeed data and be cautious. All the privacy
considerations of [RFC8805] Section 4 apply to this document. considerations of Section 4 of [RFC8805] apply to this document.
Where [RFC8805] provided the ability to publish location data, this Where [RFC8805] provided the ability to publish location data, this
document makes bulk access to those data readily available. This is document makes bulk access to those data readily available. This is
a goal, not an accident. a goal, not an accident.
7. Security Considerations 7. Security Considerations
It is generally prudent for a consumer of geofeed data to also use It is generally prudent for a consumer of geofeed data to also use
other sources to cross-validate the data. All the Security other sources to cross validate the data. All the security
Considerations of [RFC8805] apply here as well. considerations of [RFC8805] apply here as well.
As mentioned in Section 4, many RPSL repositories have weak if any As mentioned in Section 4, many RPSL repositories have weak, if any,
authentication. This allows spoofing of inetnum: objects pointing to authentication. This allows spoofing of inetnum: objects pointing to
malicious geofeed files. Section 4 suggests an unfortunately complex malicious geofeed files. Section 4 suggests an unfortunately complex
method for stronger authentication based on the RPKI. method for stronger authentication based on the RPKI.
For example, if an inetnum: for a wide address range (e.g. a /16) For example, if an inetnum: for a wide address range (e.g., a /16)
points to an RPKI-signed geofeed file, a customer or attacker could points to an RPKI-signed geofeed file, a customer or attacker could
publish an unsigned equal or narrower (e.g. a /24) inetnum: in a publish an unsigned equal or narrower (e.g., a /24) inetnum: in a
whois registry which has weak authorization, abusing the rule that WHOIS registry that has weak authorization, abusing the rule that the
the most-specific inetnum: object with a geofeed reference MUST be most-specific inetnum: object with a geofeed reference MUST be used.
used.
If signatures were mandatory, the above attack would be stymied. But If signatures were mandatory, the above attack would be stymied, but
of course that is not happening anytime soon. of course that is not happening anytime soon.
The RPSL providers have had to throttle fetching from their servers The RPSL providers have had to throttle fetching from their servers
due to too-frequent queries. Usually they throttle by the querying due to too-frequent queries. Usually, they throttle by the querying
IP address or block. Similar defenses will likely need to be IP address or block. Similar defenses will likely need to be
deployed by geofeed file servers. deployed by geofeed file servers.
8. IANA Considerations 8. IANA Considerations
IANA is asked to register object identifiers for one content type in IANA has registered object identifiers for one content type in the
the "SMI Security for S/MIME CMS Content Type "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)"
(1.2.840.113549.1.9.16.1)" registry as follows: registry as follows:
Description OID Specification
-----------------------------------------------------------------
id-ct-geofeedCSVwithCRLF 1.2.840.113549.1.9.16.1.47 [RFC-TBD]
9. Acknowledgments +=========+==========================+============+
| Decimal | Description | References |
+=========+==========================+============+
| 47 | id-ct-geofeedCSVwithCRLF | RFC 9092 |
+---------+--------------------------+------------+
Thanks to Rob Austein for CMS and detached signature clue. George Table 1
Michaelson for the first and substantial external review, Erik Kline
who was too shy to agree to co-authorship. Additionally, we express
our gratitude to early implementors, including Menno Schepers, Flavio
Luciani, Eric Dugas, Job Snijders who provided running code, and
Kevin Pack. Also, to geolocation providers that are consuming
geofeeds with this described solution, Jonathan Kosgei (ipdata.co),
Ben Dowling (ipinfo.io), and Pol Nisenblat (bigdatacloud.com). For
an amazing number of helpful reviews we thank Adrian Farrel, Antonio
Prado, Francesca Palombini, Jean-Michel Combes (INTDIR), John
Scudder, Kyle Rose (SECDIR), Martin Duke, Murray Kucherawy, Paul
Kyzivat (GENART), Rob Wilton, and Roman Danyliw. The authors also
thank George Michaelson, the awesome document shepherd.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999, DOI 10.17487/RFC2622, June 1999,
skipping to change at page 12, line 24 skipping to change at line 532
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-Published IP Geolocation Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/info/rfc8805>. <https://www.rfc-editor.org/info/rfc8805>.
[RFC8933] Housley, R., "Update to the Cryptographic Message Syntax [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax
(CMS) for Algorithm Identifier Protection", RFC 8933, (CMS) for Algorithm Identifier Protection", RFC 8933,
DOI 10.17487/RFC8933, October 2020, DOI 10.17487/RFC8933, October 2020,
<https://www.rfc-editor.org/info/rfc8933>. <https://www.rfc-editor.org/info/rfc8933>.
10.2. Informative References 9.2. Informative References
[geofeed-finder] [GEOFEED-FINDER]
Massimo Candela, "geofeed-finder", "geofeed-finder", commit 5f557a4, June 2021,
<https://github.com/massimocandela/geofeed-finder>. <https://github.com/massimocandela/geofeed-finder>.
[I-D.ietf-sidrops-rpki-rta] [INET6NUM] RIPE NCC, "Description of the INET6NUM Object", October
Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels, 2019, <https://www.ripe.net/manage-ips-and-
T., and M. Hoffmann, "A profile for Resource Tagged
Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work
in progress), January 2021.
[I-D.spaghetti-sidrops-rpki-rsc]
Snijders, J., "RPKI Signed Checklists", draft-spaghetti-
sidrops-rpki-rsc-03 (work in progress), February 2021.
[INET6NUM]
RIPE, "Description of the INET6NUM Object",
<https://www.ripe.net/manage-ips-and-
asns/db/support/documentation/ripe-database-documentation/ asns/db/support/documentation/ripe-database-documentation/
rpsl-object-types/4-2-descriptions-of-primary- rpsl-object-types/4-2-descriptions-of-primary-
objects/4-2-3-description-of-the-inet6num-object>. objects/4-2-3-description-of-the-inet6num-object>.
[INETNUM] RIPE, "Description of the INETNUM Object", [INETNUM] RIPE NCC, "Description of the INETNUM Object", June 2020,
<https://www.ripe.net/manage-ips-and- <https://www.ripe.net/manage-ips-and-
asns/db/support/documentation/ripe-database-documentation/ asns/db/support/documentation/ripe-database-documentation/
rpsl-object-types/4-2-descriptions-of-primary- rpsl-object-types/4-2-descriptions-of-primary-
objects/4-2-4-description-of-the-inetnum-object>. objects/4-2-4-description-of-the-inetnum-object>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<https://www.rfc-editor.org/info/rfc959>. <https://www.rfc-editor.org/info/rfc959>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>. <https://www.rfc-editor.org/info/rfc3912>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5485] Housley, R., "Digital Signatures on Internet-Draft [RFC5485] Housley, R., "Digital Signatures on Internet-Draft
Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009,
<https://www.rfc-editor.org/info/rfc5485>. <https://www.rfc-editor.org/info/rfc5485>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol (RDAP) Query Format", RFC 7482,
DOI 10.17487/RFC7482, March 2015,
<https://www.rfc-editor.org/info/rfc7482>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects", "Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015, RFC 7485, DOI 10.17487/RFC7485, March 2015,
<https://www.rfc-editor.org/info/rfc7485>. <https://www.rfc-editor.org/info/rfc7485>.
[RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy [RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy
Specification Language (RPSL) Objects with Resource Public Specification Language (RPSL) Objects with Resource Public
Key Infrastructure (RPKI) Signatures", RFC 7909, Key Infrastructure (RPKI) Signatures", RFC 7909,
DOI 10.17487/RFC7909, June 2016, DOI 10.17487/RFC7909, June 2016,
<https://www.rfc-editor.org/info/rfc7909>. <https://www.rfc-editor.org/info/rfc7909>.
[RIPE-DB] RIPE, "RIPE Database Documentation", [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RIPE-DB] RIPE NCC, "RIPE Database Documentation",
<https://www.ripe.net/manage-ips-and- <https://www.ripe.net/manage-ips-and-
asns/db/support/documentation/ripe-database- asns/db/support/documentation/ripe-database-
documentation>. documentation>.
[RIPE181] RIPE, "Representation Of IP Routing Policies In A Routing [RIPE181] RIPE NCC, "Representation Of IP Routing Policies In A
Registry", Routing Registry", October 1994,
<https://www.ripe.net/publications/docs/ripe-181>. <https://www.ripe.net/publications/docs/ripe-181>.
[RIPE81] RIPE, "Representation Of IP Routing Policies In The RIPE [RIPE81] RIPE NCC, "Representation Of IP Routing Policies In The
Database", RIPE Database", February 1993,
<https://www.ripe.net/publications/docs/ripe-081>. <https://www.ripe.net/publications/docs/ripe-081>.
[RPKI-RSC] Snijders, J., Harrison, T., and B. Maddison, "Resource
Public Key Infrastructure (RPKI) object profile for Signed
Checklist (RSC)", Work in Progress, Internet-Draft, draft-
ietf-sidrops-rpki-rsc-04, 31 May 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-rsc-04>.
[RPKI-RTA] Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,
T., and M. Hoffmann, "A profile for Resource Tagged
Attestations (RTAs)", Work in Progress, Internet-Draft,
draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-rta-00>.
Appendix A. Example Appendix A. Example
This appendix provides an example, including a trust anchor, a CA This appendix provides an example that includes a trust anchor, a CA
certificate subordinate to the trust anchor, an end-entity certificate subordinate to the trust anchor, an end-entity
certificate subordinate to the CA for signing the geofeed, and a certificate subordinate to the CA for signing the geofeed, and a
detached signature. detached signature.
The trust anchor is represented by a self-signed certificate. As The trust anchor is represented by a self-signed certificate. As
usual in the RPKI, the trust anchor has authority over all IPv4 usual in the RPKI, the trust anchor has authority over all IPv4
address blocks, all IPv6 address blocks, and all AS numbers. address blocks, all IPv6 address blocks, and all Autonomous System
(AS) numbers.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEPjCCAyagAwIBAgIUPsUFJ4e/7pKZ6E14aBdkbYzms1gwDQYJKoZIhvcNAQEL MIIEPjCCAyagAwIBAgIUPsUFJ4e/7pKZ6E14aBdkbYzms1gwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMDA5MDMxODU0NTRaFw0zMDA5 BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMDA5MDMxODU0NTRaFw0zMDA5
MDExODU0NTRaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB MDExODU0NTRaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCelMmMDCGBhqn/a3VrNAoKMr1HVLKxGoG7VF/13HZJ AQUAA4IBDwAwggEKAoIBAQCelMmMDCGBhqn/a3VrNAoKMr1HVLKxGoG7VF/13HZJ
0twObUZlh3Jz+XeD+kNAURhELWTrsgdTkQQfqinqOuRemxTl55+x7nLpe5nmwaBH 0twObUZlh3Jz+XeD+kNAURhELWTrsgdTkQQfqinqOuRemxTl55+x7nLpe5nmwaBH
XqqDOHubmkbAGanGcm6T/rD9KNk1Z46Uc2p7UYu0fwNO0mo0aqFL2FSyvzZwziNe XqqDOHubmkbAGanGcm6T/rD9KNk1Z46Uc2p7UYu0fwNO0mo0aqFL2FSyvzZwziNe
g7ELYZ4a3LvGn81JfP/JvM6pgtoMNuee5RV6TWaz7LV304ICj8Bhphy/HFpOA1rb g7ELYZ4a3LvGn81JfP/JvM6pgtoMNuee5RV6TWaz7LV304ICj8Bhphy/HFpOA1rb
O9gs8CUMgqz+RroAIa8cV8gbF/fPCz9Ofl7Gdmib679JxxFrW4wRJ0nMJgJmsZXq O9gs8CUMgqz+RroAIa8cV8gbF/fPCz9Ofl7Gdmib679JxxFrW4wRJ0nMJgJmsZXq
skipping to change at page 21, line 33 skipping to change at line 947
O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo
Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz
vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc
DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf
taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc
PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ
E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV
iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y= iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y=
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
Signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF), Signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF)
yields the following detached CMS signature. yields the following detached CMS signature.
# RPKI Signature: 192.0.2.0 - 192.0.2.255 # RPKI Signature: 192.0.2.0 - 192.0.2.255
# MIIGjwYJKoZIhvcNAQcCoIIGgDCCBnwCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # MIIGjwYJKoZIhvcNAQcCoIIGgDCCBnwCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggSpMIIEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu # IhvcNAQkQAS+gggSpMIIEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
# QwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR # QwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
# TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMTA1MjAxNjA1NDVaFw0yMjAzMTYx # TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMTA1MjAxNjA1NDVaFw0yMjAzMTYx
# NjA1NDVaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM # NjA1NDVaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
# 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT # 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
# QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg # QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
skipping to change at page 22, line 44 skipping to change at line 989
# DQEJEAEvMBwGCSqGSIb3DQEJBTEPFw0yMTA1MjAxNjI4MzlaMC8GCSqGSIb3DQE # DQEJEAEvMBwGCSqGSIb3DQEJBTEPFw0yMTA1MjAxNjI4MzlaMC8GCSqGSIb3DQE
# JBDEiBCAr4vKeUvHJINsE0YQwUMxoo48qrOU+iPuFbQR8qX3BFjANBgkqhkiG9w # JBDEiBCAr4vKeUvHJINsE0YQwUMxoo48qrOU+iPuFbQR8qX3BFjANBgkqhkiG9w
# 0BAQEFAASCAQB85HsCBrU3EcVOcf4nC6Z3jrOjT+fVlyTDAObF6GTNWgrxe7jSA # 0BAQEFAASCAQB85HsCBrU3EcVOcf4nC6Z3jrOjT+fVlyTDAObF6GTNWgrxe7jSA
# Inyf51UzuIGqhVY3sQiiXbdWcVYtPb4118KvyeXh8A/HLp4eeAJntl9D3igt38M # Inyf51UzuIGqhVY3sQiiXbdWcVYtPb4118KvyeXh8A/HLp4eeAJntl9D3igt38M
# o84q5pf9pTQXx3hbsm51ilpOip/TKVMqzE42s6OPox3M0+6eKH3/vBKnw1s1ayM # o84q5pf9pTQXx3hbsm51ilpOip/TKVMqzE42s6OPox3M0+6eKH3/vBKnw1s1ayM
# 0MUnPDTBfZL3JJEGPWfIZHEcrypevbqR7Jjsz5vp0qyF2D9v+w+nyhZOPmuePm7 # 0MUnPDTBfZL3JJEGPWfIZHEcrypevbqR7Jjsz5vp0qyF2D9v+w+nyhZOPmuePm7
# YqLyOw/E99PVBs9uI+hmBiCz/BK2Z3VRjrrlrUU+49eldSTkZ2sJyhCbbV2Ufgi # YqLyOw/E99PVBs9uI+hmBiCz/BK2Z3VRjrrlrUU+49eldSTkZ2sJyhCbbV2Ufgi
# S2FOquAgJzjilyN3BDQLV8Rp9cGh0PpVslKH2na # S2FOquAgJzjilyN3BDQLV8Rp9cGh0PpVslKH2na
# End Signature: 192.0.2.0 - 192.0.2.255 # End Signature: 192.0.2.0 - 192.0.2.255
Acknowledgments
Thanks to Rob Austein for CMS and detached signature clue, George
Michaelson for the first and substantial external review, and Erik
Kline who was too shy to agree to coauthorship. Additionally, we
express our gratitude to early implementors, including Menno
Schepers; Flavio Luciani; Eric Dugas; Job Snijders, who provided
running code; and Kevin Pack. Also, thanks to the following
geolocation providers who are consuming geofeeds with this described
solution: Jonathan Kosgei (ipdata.co), Ben Dowling (ipinfo.io), and
Pol Nisenblat (bigdatacloud.com). For an amazing number of helpful
reviews, we thank Adrian Farrel, Antonio Prado, Francesca Palombini,
Jean-Michel Combes (INTDIR), John Scudder, Kyle Rose (SECDIR), Martin
Duke, Murray Kucherawy, Paul Kyzivat (GENART), Rob Wilton, and Roman
Danyliw. The authors also thank George Michaelson, the awesome
document shepherd.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
IIJ & Arrcus IIJ & Arrcus
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
United States of America United States of America
Email: randy@psg.com Email: randy@psg.com
Massimo Candela Massimo Candela
NTT NTT
Siriusdreef 70-72 Siriusdreef 70-72
Hoofddorp 2132 WT 2132 WT Hoofddorp
Netherlands Netherlands
Email: massimo@ntt.net Email: massimo@ntt.net
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US United States of America
Email: warren@kumari.net Email: warren@kumari.net
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
USA United States of America
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 90 change blocks. 
222 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/