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