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

[Randy Bush <[e-mail]>]

>>> 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