On Fri, May 21, 2021 at 12:43:24PM -0700, Randy Bush wrote: > >>> 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.
I think DNSSEC was always in the IETF stream, though -- DMARC started as ISE, and we've had an IETF WG open for 6(?) years trying to bring it into the IETF stream. > > (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 That seems like it should have useful/workable properties. We're now assigning semantics to the stuff after "RPKI Signature"/"End Signature", that maybe didn't previously have important semantics. Rob should probably weigh in on how much review such a change would need. -Ben > > nit: comma before "abusing" to aid readability. > > ack > > randy _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
