>>> Publishing this document on the stanards-track does make one wonder >>> whether RFC 8805 should be adopted at least into the IETF stream and >>> possibly to the standards-track as well... >> >> and it could use a bit of work in the process. can you say "let's open >> a can of worms?" but yes, geofeed has seriously 8805 deployment, and it >> is showing cracks. > > The analogies to DMARC do kind of write themselves...
i nominate dnssec as the poster child here. first version was not deployable at all. > (We do have plenty of examples of shiny cryptographic schemes that remain > mostly unused, but I will refrain from naming names...) and some that should have been unused >>> Maybe I'm just confused about what "covered by he range of the inetnum:" >>> means, but I only see (at least so far) requirements that the signing >>> cert cover all addresses in the file, and that we fetch from the >>> most-specific inetnum: object with a geofeed reference. Can't I still >>> sign with a cert that covers a broader range of addresses than the >>> intenum: object used to fetch? >> >> i am trying to think of two examples [ yes, certs and inetnum:s may >> express ranges as well as cidr blocks ] >> >> two inetnums: >> 1.2.3.0 - 1.2.3.7 >> 1.2.3.6 - 1.2.3.13 >> and a cert for 1.2.3.0 - 1.2.3.13 >> >> and conversely >> >> two certs: >> 1.2.3.0 - 1.2.3.7 >> 1.2.3.6 - 1.2.3.13 >> and an inetnum: for 1.2.3.0 - 1.2.3.13 > > IIUC you'd need to subdivide the inetnums in order for the signatures to > work? [ excuse i am running on 36 hours no sleep ] currently we say The address range of the signing certificate MUST cover all prefixes in the geofeed file it signs; and therefore must be covered by the range of the inetnum:. i.e. a cert for 1.2.3.0/24 can not sign either example. i don't think that second restrictive clause is a logical conclusion from the first. i suggest that, for simplicity and a redundancy check, the wrapper MUST be # RPKI Signature: A # # End Signature: B where A-B MUST be the range of the inetnum: pointing to the file and that the signing cert MUST cover A-Z, though could be wider. i will work the text > nit: comma before "abusing" to aid readability. ack randy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg