< draft-ietf-opsawg-finding-geofeeds-13.txt   draft-ietf-opsawg-finding-geofeeds-14.txt >
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ & Arrcus Internet-Draft IIJ & Arrcus
Intended status: Standards Track M. Candela Intended status: Standards Track M. Candela
Expires: November 21, 2021 NTT Expires: November 22, 2021 NTT
W. Kumari W. Kumari
Google Google
R. Housley R. Housley
Vigil Security Vigil Security
May 20, 2021 May 21, 2021
Finding and Using Geofeed Data Finding and Using Geofeed Data
draft-ietf-opsawg-finding-geofeeds-13 draft-ietf-opsawg-finding-geofeeds-14
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 CSV files, and describes an optional scheme to use the
Routing Public Key Infrastructure to authenticate the geofeed data Routing Public Key Infrastructure to authenticate the geofeed data
CSV files. CSV files.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 21, 2021. This Internet-Draft will expire on November 22, 2021.
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
skipping to change at page 5, line 42 skipping to change at page 5, line 42
A single optional authenticator MAY be appended to a [RFC8805] A single optional authenticator MAY be appended to a [RFC8805]
geofeed file. It is a digest of the main body of the file signed by geofeed file. It is a digest of the main body of the file signed by
the private key of the relevant RPKI certificate for the covering the private key of the relevant RPKI certificate for the 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 its 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. Trailing space characters MUST NOT appear on a line of text. text. A blank line is represented solely by the <CRLF> sequence.
That is, space or tab characters must not immediately preceed a For robustness, any non-printable characters MUST NOT be changed by
<CRLF> sequence. Thus, a blank line is represented solely by the canonicalization. Trailing blank lines MUST NOT appear at the end of
<CRLF> sequence. Other non-printable characters, such as backspace, the file. That is, the file must not end with multiple consecutive
are not expected. For robustness, any non-printable characters MUST <CRLF> sequences. Any end-of-file marker used by an operating system
NOT be changed by canonicalization. Trailing blank lines MUST NOT is not considered to be part of the file content. When present, such
appear at the end of the file. That is, the file must not end with end-of-file markers MUST NOT be processed by the digital signature
multiple consecutive <CRLF> sequences. Any end-of-file marker used algorithm.
by an operating system 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 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 which is
then padded BASE64 encoded (as per [RFC4648]) Section 4, and line then padded BASE64 encoded (as per [RFC4648] Section 4), 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 calculating the message digest on the
SignerInfo SignedAttributes [RFC8933]. The message digest algorithm SignerInfo SignedAttributes [RFC8933]. The message digest algorithm
identifier MUST appear in both the SigenedData identifier MUST appear in both the SigenedData
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; and therefore must be covered by the in the geofeed file it signs; and therefore must be covered by the
skipping to change at page 8, line 6 skipping to change at page 8, line 6
# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
... ...
# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk= # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
# End Signature: 192.0.2.0/24 # End Signature: 192.0.2.0/24
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. The IP address range MUST present following the model as shown. Their IP address range MUST
match that of the signer's certificate. match that of the inetnum: URL followed to the file.
[I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a [I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a
Cryptographic Message Syntax (CMS) profile for a general purpose Cryptographic Message Syntax (CMS) profile for a general purpose
listing of checksums (a 'checklist'), for use with the Resource listing of checksums (a 'checklist'), for use with the Resource
Public Key Infrastructure (RPKI). It provides usable, albeit Public Key Infrastructure (RPKI). It provides usable, albeit
complex, code to sign geofeed files. complex, code to sign geofeed files.
[I-D.ietf-sidrops-rpki-rta] describes a Cryptographic Message Syntax [I-D.ietf-sidrops-rpki-rta] describes a Cryptographic Message Syntax
(CMS) profile for a general purpose Resource Tagged Attestation (RTA) (CMS) profile for a general purpose Resource Tagged Attestation (RTA)
based on the RPKI. While this is expected to become applicable in based on the RPKI. While this is expected to become applicable in
skipping to change at page 8, line 40 skipping to change at page 8, line 40
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 they have 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 CA
may issue a subordinate certificate exclusively for the purpose as may issue a subordinate certificate exclusively for the purpose as
shown in Appendix A. shown in Appendix A.
skipping to change at page 9, line 37 skipping to change at page 9, line 37
[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 [RFC8805] Section 4 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. document makes bulk access to those data readily available. This is
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 prefix (e.g. a /16) points to For example, if an inetnum: for a wide prefix (e.g. a /16) points to
an RPKI-signed geofeed file, a customer or attacker could publish an an RPKI-signed geofeed file, a customer or attacker could publish an
unsigned equal or narrower (e.g. a /24) inetnum: in a whois registry unsigned equal or narrower (e.g. a /24) inetnum: in a whois registry
which has weak authorization abusing the rule that the most-specific which has weak authorization, abusing the rule that the most-specific
inetnum: object with a geofeed reference MUST be used. inetnum: object with a geofeed reference MUST be 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.
 End of changes. 10 change blocks. 
21 lines changed or deleted 19 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/