Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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