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

-11 pushed with massimo suggestion dealing with iesg reviews

Browse source
This commit is contained in:
Randy Bush 2024-02-22 17:51:43 -08:00
parent dcb5a9bffb
commit df49758b39
1 changed files with 55 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

102
draft-ietf-opsawg-9092-update.xml
View file

@ -8,7 +8,7 @@
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-opsawg-9092-update-10"
<rfc category="std" docName="draft-ietf-opsawg-9092-update-11"
submissionType="IETF" consensus="true" ipr="trust200902"
obsoletes="9092" version="2" >
@ -17,7 +17,7 @@
<title abbrev="Finding and Using Geofeed Data">Finding and Using Geofeed Data</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>IIJ &amp; Arrcus</organization>
<organization>IIJ Research &amp; Arrcus</organization>
<address>
<postal>
<street>5147 Crystal Springs</street>
@ -224,7 +224,8 @@
modified and extensively enhanced in the Regional Internet
Registry (RIR) community, mostly by RIPE <xref target="RIPE-DB"
format="default"/>. At the time of publishing this document,
change control effectively lies in the operator community.
change control of RPSL effectively lies in the operator
community.
</t>
<t>
@ -278,9 +279,8 @@
<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
MUST be able to consume both the remarks: and
geofeed: forms.
consumers looking at inetnum: objects to find geofeed URLs MUST
be able to consume both the remarks: and geofeed: forms.
</t>
<t>
@ -292,15 +292,17 @@
<t>
Any particular inetnum: object SHOULD have, at most, one geofeed
reference, whether a remarks: or a proper geofeed: attribute
when it is implemented. A geofeed: attribute is preferred, of
course, if the RIR supports it. If there is more than one type
of attribute in the intetnum: object, the geofeed: attribute
SHOULD be used.
when it is implemented. As the remarks: form can not be
formally checked by the RIR, this can not be formally enforced.
A geofeed: attribute is preferred, of course, if the RIR
supports it. If there is more than one type of attribute in the
intetnum: object, the geofeed: attribute MUST be used.
</t>
<t>
For inetnum:s covering the same address range, or an inetnum:
with both remarks: and geofeed: attributes, a signed geofeed
file SHOULD be preferred over an unsigned file.
For inetnum:s covering the same address range, a signed geofeed
file MUST be preferred over an unsigned file. If none are
signed, or more than one is signed, the (signed) inetnum: with
the most recent last-modified: attribute MUST be preferred.
</t>
<t>
If a geofeed file describes multiple disjoint ranges of IP
@ -315,17 +317,8 @@
more than one registry.
</t>
<t>
When geofeed references are provided by multiple inetnum:
objects that have identical address ranges, then the geofeed
reference on the inetnum: with the most recent last-modified:
attribute SHOULD be preferred.
</t>
<t>
As inetnum: objects form a hierarchy, geofeed references
SHOULD 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 MUST be used.
When fetching, the most specific inetnum: object with a geofeed
reference MUST be used.
</t>
<t>
It is significant that geofeed data may have finer granularity
@ -360,11 +353,17 @@
</t>
<t>
When reading data from the geofeed file, one MUST ignore data
outside the referring inetnum: object's address range. This is
to avoid importing data about ranges not under the control of
the operator. If geofeed files are fetched, other location
information from the inetnum: MUST be ignored.
When reading data from an unsigned geofeed file, one MUST ignore
data outside the referring inetnum: object's address range.
This is to avoid importing data about ranges not under the
control of the operator. Note that signed files MUST only
contain prefixes within the referring inetnum:'s range as
mandated in <xref target="auth"/>.
</t>
<t>
If geofeed files are fetched, other location information from
the inetnum: MUST be ignored.
</t>
<t>
@ -379,10 +378,10 @@
inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed_2
]]></sourcecode>
Since geofeed_1 contains geolocation data about 192.0.2.0/29,
it is discarded because 192.0.2.0/24 is within the more
specific inetnum: covering the address range and that inetnum:
has a geofeed reference.
An application looking for geofeed data for 192.0.2.0/29, MUST
ignore data in geofeed_1 because 192.0.2.0/29 is within the
more specific 192.0.2.0/24 inetnum: covering that address range
and that inetnum: does have a geofeed reference.
</t>
<t>
@ -484,25 +483,34 @@
<t>
The address range of the signing certificate MUST cover all
prefixes in the signed geofeed file. The signing certificate
MUST NOT include the Autonomous System Identifier Delegation
certificate extension <xref target="RFC3779"/>.
prefixes in the signed geofeed file. If not, the authenticator
is invalid.
</t>
<t>
The signing certificate MUST NOT include the Autonomous System
Identifier Delegation certificate extension <xref
target="RFC3779"/>. If it is present, the authenticator is
invalid.
</t>
<t>
As with many other RPKI signed objects, the IP Address
Delegation certificate extension MUST NOT use the "inherit"
capability defined in Section 2.2.3.5 of <xref
target="RFC3779"/>. An IP Address Delegation extension using
"inherit" would complicate processing. The implementation would
have to build the certification path from the end-entity to the
trust anchor, then validate the path from the trust anchor to
the end-entity, and then the parameter would have to be
remembered when the validated public key was used to validate a
signature on a CMS object. Having to remember things from
certification path validation for use with CMS object processing
would be quite complex and error prone. And, the certificates
do not get that much bigger by repeating the information.
target="RFC3779"/>. If "inherit" is used, the authenticator is
invalid.
</t>
<t>
An IP Address Delegation extension using "inherit" would
complicate processing. The implementation would have to build
the certification path from the end-entity to the trust anchor,
then validate the path from the trust anchor to the end-entity,
and then the parameter would have to be remembered when the
validated public key was used to validate a signature on a CMS
object. Having to remember things from certification path
validation for use with CMS object processing would be quite
complex and error prone. And, the certificates do not get that
much bigger by repeating the information.
</t>
<t>
@ -773,7 +781,7 @@
<t>
The consumer of geofeed data SHOULD fetch and process the data
themselves. Importing datasets produced and/or processed by a
third-party places ill-advised trust in the third-party.
third-party places significant trust in the third-party.
</t>
<t>
As mentioned in <xref target="auth" format="default"/>, some