randy/draft-9092update
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

russ's one paragraph hack

Browse source
This commit is contained in:
Randy Bush 2022-12-05 13:27:41 -08:00
parent 5deadcb09b
commit ae2a50bcd8
1 changed files with 187 additions and 158 deletions
Download patch file Download diff file Expand all files Collapse all files

333
draft-ymbk-9092update.xml
View file

@ -13,7 +13,7 @@
<front>
<title abbrev="Finding Geofeeds">Finding and Using Geofeed Data</title>
<title abbrev="Finding Geofeeds">A Minor Update to Finding and Using Geofeed Data</title>
<seriesInfo name="RFC" value="9092"/>
@ -140,29 +140,30 @@
<section anchor="gf" numbered="true" toc="default">
<name>Geofeed Files</name>
<t>
Geofeed files are described in <xref target="RFC8805" format="default"/>. They
provide a facility for an IP address resource "owner" to
associate those IP addresses to geographic locales.
Geofeed files are described in <xref target="RFC8805"
format="default"/>. They provide a facility for an IP address
resource "owner" to associate those IP addresses to geographic
locales.
</t>
<t>
Content providers and other parties who wish to locate an IP address
to a geographic locale need to find the relevant geofeed data. In
<xref target="inetnum" format="default"/>, this document specifies how
to find the relevant geofeed <xref target="RFC8805" format="default"/>
file given 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 <xref target="inetnum" format="default"/>, this
document specifies how to find the relevant geofeed <xref
target="RFC8805" format="default"/> file given an IP address.
</t>
<t>
Geofeed data for large providers with significant horizontal
scale 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 prefixes, if dual IPv4/IPv6 spaces are represented,
etc.
data for many prefixes, if dual IPv4/IPv6 spaces are
represented, etc.
</t>
<t>
Geofeed data do have privacy considerations (see <xref
target="privacy" format="default"/>); this process makes bulk access
to those data easier.
target="privacy" format="default"/>); this process makes bulk
access to those data easier.
</t>
<t>
This document also suggests an optional signature to strongly
@ -172,34 +173,38 @@
<section anchor="inetnum" numbered="true" toc="default">
<name>inetnum: Class</name>
<t>
The original RPSL specifications starting with <xref target="RIPE81" format="default"/>, <xref target="RIPE181" format="default"/>, and a trail of
subsequent documents were written by the RIPE community. The IETF
standardized RPSL in <xref target="RFC2622" format="default"/> and <xref target="RFC4012" format="default"/>. Since then, it has been modified and
extensively enhanced in the Regional Internet Registry (RIR)
community, mostly by RIPE <xref target="RIPE-DB" format="default"/>. Currently,
change control effectively lies in the operator community.
The original RPSL specifications starting with <xref
target="RIPE81" format="default"/>, <xref target="RIPE181"
format="default"/>, and a trail of subsequent documents were
written by the RIPE community. The IETF standardized RPSL in
<xref target="RFC2622" format="default"/> and <xref
target="RFC4012" format="default"/>. Since then, it has been
modified and extensively enhanced in the Regional Internet
Registry (RIR) community, mostly by RIPE <xref target="RIPE-DB"
format="default"/>. Currently, change control effectively lies
in the operator community.
</t>
<t>
The RPSL, and <xref target="RFC2725" format="default"/> and <xref target="RFC4012" format="default"/> used by the
Regional Internet Registries (RIRs), specify the inetnum:
database class. Each of these objects describes an IP address
range and its attributes. The inetnum: objects form a hierarchy
ordered on the address space.
The RPSL, and <xref target="RFC2725" format="default"/> and
<xref target="RFC4012" format="default"/> used by the Regional
Internet Registries (RIRs), specify the inetnum: database class.
Each of these objects describes an IP address range and its
attributes. The inetnum: objects form a hierarchy ordered on
the address space.
</t>
<t>
Ideally, RPSL would be augmented to define a new RPSL geofeed:
attribute in the inetnum: class. Until such time, this document
defines the syntax of a Geofeed remarks: attribute, which contains an
HTTPS URL of a geofeed file. The format of the inetnum: geofeed
remarks: attribute <bcp14>MUST</bcp14> be as in this example,
"remarks: Geofeed ", where the token "Geofeed " <bcp14>MUST</bcp14> be
case sensitive, followed by a URL that will vary, but it
<bcp14>MUST</bcp14> refer only to a single geofeed <xref
target="RFC8805" format="default"/> file.
defines the syntax of a Geofeed remarks: attribute, which
contains an HTTPS URL of a geofeed file. The format of the
inetnum: geofeed remarks: attribute <bcp14>MUST</bcp14> be as in
this example, "remarks: Geofeed ", where the token "Geofeed "
<bcp14>MUST</bcp14> be case sensitive, followed by a URL that
will vary, but it <bcp14>MUST</bcp14> refer only to a single
geofeed <xref target="RFC8805" format="default"/> file.
</t>
<sourcecode type="rpsl"> <![CDATA[
@ -207,47 +212,49 @@
remarks: Geofeed https://example.com/geofeed.csv
]]></sourcecode>
<t>
While we leave global agreement of RPSL modification to the relevant
parties, we specify that a proper geofeed: attribute in the inetnum:
class <bcp14>MUST</bcp14> be "geofeed:" and <bcp14>MUST</bcp14> be
followed by a single URL that will vary, but it <bcp14>MUST</bcp14>
refer only to a single geofeed <xref target="RFC8805"
format="default"/> file.
While we leave global agreement of RPSL modification to the
relevant parties, we specify that a proper geofeed: attribute in
the inetnum: class <bcp14>MUST</bcp14> be "geofeed:" and
<bcp14>MUST</bcp14> be followed by a single URL that will vary,
but it <bcp14>MUST</bcp14> refer only to a single geofeed <xref
target="RFC8805" format="default"/> file.
</t>
<sourcecode type="rpsl"><![CDATA[
inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed.csv
]]></sourcecode>
<t>
Registries <bcp14>MAY</bcp14>, for the interim, provide a mix of the remarks:
attribute form and the geofeed: attribute form.
Registries <bcp14>MAY</bcp14>, for the interim, provide a mix of
the remarks: attribute form and the geofeed: attribute form.
</t>
<t>
The URL uses HTTPS, so the WebPKI provides authentication, integrity,
and confidentiality for the fetched geofeed file. However, the WebPKI
can not provide authentication of IP address space assignment. In
contrast, the RPKI (see <xref target="RFC6481" format="default"/>) can
be used to authenticate IP space assignment; see optional
authentication in <xref target="auth" format="default"/>.
The URL uses HTTPS, so the WebPKI provides authentication,
integrity, and confidentiality for the fetched geofeed file.
However, the WebPKI can not provide authentication of IP address
space assignment. In contrast, the RPKI (see <xref
target="RFC6481" format="default"/>) can be used to authenticate
IP space assignment; see optional authentication in <xref
target="auth" format="default"/>.
</t>
<t>
Until all producers of inetnum: objects, i.e., the RIRs, state that they
have migrated to supporting a geofeed: attribute, consumers
looking at inetnum: objects to find geofeed URLs <bcp14>MUST</bcp14> be able to
consume both the remarks: and geofeed: forms.
Until all producers of inetnum: objects, i.e., the RIRs, state
that they have migrated to supporting a geofeed: attribute,
consumers looking at inetnum: objects to find geofeed URLs
<bcp14>MUST</bcp14> be able to consume both the remarks: and
geofeed: forms.
The migration not only implies that the RIRs support the geofeed:
attribute, but that all registrants have migrated any inetnum: objects
from remarks: to geofeed: attributes.
The migration not only implies that the RIRs support the
geofeed: attribute, but that all registrants have migrated any
inetnum: objects from remarks: to geofeed: attributes.
</t>
<t>
Any particular inetnum: object <bcp14>MUST</bcp14> have, at most, one geofeed
reference, whether a remarks: or a proper geofeed: attribute
when it is implemented. If there is more than one, all are
ignored.
Any particular inetnum: object <bcp14>MUST</bcp14> have, at
most, one geofeed reference, whether a remarks: or a proper
geofeed: attribute when it is implemented. If there is more
than one, all are ignored.
</t>
<t>
If a geofeed CSV file describes multiple disjoint ranges of IP
@ -263,11 +270,11 @@
attribute <bcp14>SHOULD</bcp14> be preferred.
</t>
<t>
As inetnum: objects form a hierarchy, geofeed references <bcp14>SHOULD</bcp14>
be at the lowest applicable inetnum: object covering the
relevant address ranges in the referenced geofeed file. When
fetching, the most specific inetnum: object with a geofeed
reference <bcp14>MUST</bcp14> be used.
As inetnum: objects form a hierarchy, geofeed references
<bcp14>SHOULD</bcp14> be at the lowest applicable inetnum:
object covering the relevant address ranges in the referenced
geofeed file. When fetching, the most specific inetnum: object
with a geofeed reference <bcp14>MUST</bcp14> be used.
</t>
<t>
It is significant that geofeed data may have finer granularity
@ -276,12 +283,13 @@
which P has been subdivided into one or more longer prefixes.
</t>
<t>
Currently, the registry data published by ARIN are not the same RPSL as
that of the other registries (see <xref target="RFC7485"
Currently, the registry data published by ARIN are not the same
RPSL as that of the other registries (see <xref target="RFC7485"
format="default"/> for a survey of the WHOIS Tower of Babel);
therefore, when fetching from ARIN via FTP <xref target="RFC0959"
format="default"/>, WHOIS <xref target="RFC3912" format="default"/>,
the Registration Data Access Protocol (RDAP) <xref target="RFC9082"
therefore, when fetching from ARIN via FTP <xref
target="RFC0959" format="default"/>, WHOIS <xref
target="RFC3912" format="default"/>, the Registration Data
Access Protocol (RDAP) <xref target="RFC9082"
format="default"/>, etc., the "NetRange" attribute/key
<bcp14>MUST</bcp14> be treated as "inetnum", and the "Comment"
attribute <bcp14>MUST</bcp14> be treated as "remarks".
@ -293,128 +301,143 @@
<t>
The question arises whether a particular geofeed <xref
target="RFC8805" format="default"/> data set is valid, i.e., is
authorized by the "owner" of the IP address space and is authoritative
in some sense. The inetnum: that points to the geofeed <xref
target="RFC8805" format="default"/> file provides some assurance.
Unfortunately, the RPSL in many repositories is weakly authenticated
at best. An approach where RPSL was signed per <xref target="RFC7909"
format="default"/> would be good, except it would have to be deployed
by all RPSL registries, and there is a fair number of them.
authorized by the "owner" of the IP address space and is
authoritative in some sense. The inetnum: that points to the
geofeed <xref target="RFC8805" format="default"/> file provides
some assurance. Unfortunately, the RPSL in many repositories is
weakly authenticated at best. An approach where RPSL was signed
per <xref target="RFC7909" format="default"/> would be good,
except it would have to be deployed by all RPSL registries, and
there is a fair number of them.
</t>
<t>
A single optional authenticator <bcp14>MAY</bcp14> be appended to a
geofeed <xref target="RFC8805" format="default"/> file. It is a
digest of the main body of the file signed by the private key of the
relevant RPKI certificate for a covering address range. One needs a
format that bundles the relevant RPKI certificate with the signature
of the geofeed text.
A single optional authenticator <bcp14>MAY</bcp14> be appended
to a geofeed <xref target="RFC8805" format="default"/> file. It
is a digest of the main body of the file signed by the private
key of the relevant RPKI certificate for a covering address
range. One needs a format that bundles the relevant RPKI
certificate with the signature of the geofeed text.
</t>
<t>
The canonicalization procedure converts the data from their internal
character representation to the UTF-8 <xref target="RFC3629"
format="default"/> character encoding, and the &lt;CRLF&gt; sequence
<bcp14>MUST</bcp14> be used to denote the end of a line of text. A
blank line is represented solely by the &lt;CRLF&gt; sequence. For
robustness, any non-printable characters <bcp14>MUST NOT</bcp14> be
changed by canonicalization. Trailing blank lines <bcp14>MUST
NOT</bcp14> appear at the end of the file. That is, the file must not
end with multiple consecutive &lt;CRLF&gt; sequences. Any end-of-file
marker used by an operating system is not considered to be part of the
file content. When present, such end-of-file markers <bcp14>MUST
NOT</bcp14> be processed by the digital signature algorithm.
The canonicalization procedure converts the data from their
internal character representation to the UTF-8 <xref
target="RFC3629" format="default"/> character encoding, and the
&lt;CRLF&gt; sequence <bcp14>MUST</bcp14> be used to denote the
end of a line of text. A blank line is represented solely by
the &lt;CRLF&gt; sequence. For robustness, any non-printable
characters <bcp14>MUST NOT</bcp14> be changed by
canonicalization. Trailing blank lines <bcp14>MUST NOT</bcp14>
appear at the end of the file. That is, the file must not end
with multiple consecutive &lt;CRLF&gt; sequences. Any
end-of-file marker used by an operating system is not considered
to be part of the file content. When present, such end-of-file
markers <bcp14>MUST NOT</bcp14> be processed by the digital
signature algorithm.
</t>
<t>
Should the authenticator be syntactically incorrect per the
above, the authenticator is invalid.
</t>
<t>
Borrowing detached signatures from <xref target="RFC5485"
format="default"/>, after file canonicalization, the Cryptographic
Message Syntax (CMS) <xref target="RFC5652" format="default"/> would
be used to create a detached DER-encoded signature that is then padded
BASE64 encoded (as per <xref target="RFC4648" sectionFormat="of"
section="4" format="default"/>) and line wrapped to 72 or fewer
characters. The same digest algorithm <bcp14>MUST</bcp14> be used for
calculating the message digest on content being signed, which is the
geofeed file, and for calculating the message digest on the SignerInfo
SignedAttributes <xref target="RFC8933" format="default"/>. The
message digest algorithm identifier <bcp14>MUST</bcp14> appear in both
the SignedData DigestAlgorithmIdentifiers and the SignerInfo
DigestAlgorithmIdentifier <xref target="RFC5652" format="default"/>.
format="default"/>, after file canonicalization, the
Cryptographic Message Syntax (CMS) <xref target="RFC5652"
format="default"/> would be used to create a detached
DER-encoded signature that is then padded BASE64 encoded (as per
<xref target="RFC4648" sectionFormat="of" section="4"
format="default"/>) and line wrapped to 72 or fewer characters.
The same digest algorithm <bcp14>MUST</bcp14> be used for
calculating the message digest on content being signed, which is
the geofeed file, and for calculating the message digest on the
SignerInfo SignedAttributes <xref target="RFC8933"
format="default"/>. The message digest algorithm identifier
<bcp14>MUST</bcp14> appear in both the SignedData
DigestAlgorithmIdentifiers and the SignerInfo
DigestAlgorithmIdentifier <xref target="RFC5652"
format="default"/>.
</t>
<t>
The address range of the signing certificate <bcp14>MUST</bcp14> cover all
prefixes in the geofeed file it signs.
The address range of the signing certificate <bcp14>MUST</bcp14>
cover all prefixes in the geofeed file it signs.
</t>
<t>
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
inetnum: objects and RPKI certificates need not align on Classless
Inter-Domain Routing (CIDR) <xref target="RFC4632"/> prefix
boundaries, while those of the CSV lines in a geofeed file do.
identical to or a subset of A. "Address range" is used here
because inetnum: objects and RPKI certificates need not align on
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
prefix boundaries, while those of the CSV lines in a geofeed
file do.
</t>
<t>
As the signer specifies the covered RPKI resources relevant to the
signature, the RPKI certificate covering the inetnum: object's address
range is included in the <xref target="RFC5652" format="default"/> CMS
SignedData certificates field.
As the signer specifies the covered RPKI resources relevant to
the signature, the RPKI certificate covering the inetnum:
object's address range is included in the <xref target="RFC5652"
format="default"/> CMS SignedData certificates field.
</t>
<t>
Identifying the private key associated with the certificate and
getting the department that controls the private key (which might be
trapped in a Hardware Security Module (HSM)) to sign the CMS blob is
left as an exercise for the implementor. On the other hand, verifying
the signature requires no complexity; the certificate, which can be
validated in the public RPKI, has the needed public key.
getting the department that controls the private key (which
might be trapped in a Hardware Security Module (HSM)) to sign
the CMS blob is left as an exercise for the implementor. On the
other hand, verifying the signature requires no complexity; the
certificate, 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 to the party performing signature validation.
Validation of the CMS signature on the geofeed file
involves:</t>
<ol spacing="normal" type="1"><li>
<t> Obtaining the signer's certificate from the CMS SignedData
CertificateSet <xref target="RFC5652" format="default"/>. The certificate
SubjectKeyIdentifier extension <xref target="RFC5280" format="default"/>
<bcp14>MUST</bcp14> match the SubjectKeyIdentifier in the CMS SignerInfo
SignerIdentifier <xref target="RFC5652" format="default"/>. If the key
identifiers do not match, then validation <bcp14>MUST</bcp14> fail.</t>
<t>
Validation of the signer's certificate <bcp14>MUST</bcp14> ensure
that it is part of the current <xref target="RFC6486"
format="default"/> manifest and that the resources are covered by
the RPKI certificate.
Obtaining the signer's certificate from the CMS SignedData
CertificateSet <xref target="RFC5652" format="default"/>. The
certificate SubjectKeyIdentifier extension <xref
target="RFC5280" format="default"/> <bcp14>MUST</bcp14> match
the SubjectKeyIdentifier in the CMS SignerInfo
SignerIdentifier <xref target="RFC5652" format="default"/>.
If the key identifiers do not match, then validation
<bcp14>MUST</bcp14> fail.</t>
<t>
Validation of the signer's certificate <bcp14>MUST</bcp14>
ensure that it is part of the current <xref target="RFC6486"
format="default"/> manifest and that the resources are covered
by the RPKI certificate.
</t>
</li>
<li>
Constructing the certification path for the signer's certificate.
All of the needed certificates are expected to be readily
available in the RPKI repository. The certification path <bcp14>MUST</bcp14>
be valid according to the validation algorithm in <xref target="RFC5280" format="default"/> and the additional checks specified in
<xref target="RFC3779" format="default"/> associated with the IP Address
Delegation certificate extension and the Autonomous System
Identifier Delegation certificate extension. If certification
path validation is unsuccessful, then validation <bcp14>MUST</bcp14> fail.
Constructing the certification path for the signer's
certificate. All of the needed certificates are expected to
be readily available in the RPKI repository. The
certification path <bcp14>MUST</bcp14> be valid according to
the validation algorithm in <xref target="RFC5280"
format="default"/> and the additional checks specified in
<xref target="RFC3779" format="default"/> associated with the
IP Address Delegation certificate extension and the Autonomous
System Identifier Delegation certificate extension. If
certification path validation is unsuccessful, then validation
<bcp14>MUST</bcp14> fail.
</li>
<li>
Validating the CMS SignedData as specified in <xref target="RFC5652" format="default"/> using the public key from the validated
signer's certificate. If the signature validation is
unsuccessful, then validation <bcp14>MUST</bcp14> fail.
Validating the CMS SignedData as specified in <xref
target="RFC5652" format="default"/> using the public key from
the validated signer's certificate. If the signature
validation is unsuccessful, then validation
<bcp14>MUST</bcp14> fail.
</li>
<li>
Verifying that the IP Address Delegation certificate extension
<xref target="RFC3779" format="default"/> covers all of the address ranges of
the geofeed file. If all of the address ranges are not
covered, then validation <bcp14>MUST</bcp14> fail.
<xref target="RFC3779" format="default"/> covers all of the
address ranges of the geofeed file. If all of the address
ranges are not covered, then validation <bcp14>MUST</bcp14>
fail.
</li>
</ol>
<t>
All of these steps <bcp14>MUST</bcp14> be successful to consider the geofeed
file signature as valid.
All of these steps <bcp14>MUST</bcp14> be successful to consider
the geofeed file signature as valid.
</t>
<t>
As the signer specifies the covered RPKI resources relevant to the
@ -422,12 +445,18 @@
range is included in the CMS SignedData certificates field <xref
target="RFC5652" format="default"/>.
</t>
<t>
As an IP Address Delegation extension using "inherit" would
complicate processing, it <bcp14>MUST NOT</bcp14> be used. This
is consistent with other RPKI signed objects.
</t>
<t>
Identifying the private key associated with the certificate and
getting the department with the Hardware Security Module (HSM) to sign
the CMS blob is left as an exercise for the implementor. On the other
hand, verifying the signature requires no complexity; the certificate,
which can be validated in the public RPKI, has the needed public key.
getting the department with the Hardware Security Module (HSM)
to sign the CMS blob is left as an exercise for the implementor.
On the other hand, verifying the signature requires no
complexity; the certificate, which can be validated in the
public RPKI, has the needed public key.
</t>
<t>
The appendix <bcp14>MUST</bcp14> be hidden as a series of "#" comments at the