Dear working group, On Fri, Jan 22, 2021 at 09:43:26PM +0000, Joe Clarke (jclarke) wrote: > Happy new year, opsawg. The draft-ietf-opsawg-finding-geofeeds draft > has undergone some discussion and with the recent -01 revision of the WG > version of the document, the authors have made all pending changes based > on feedback. > > We would like to conduct a two-week working group last call on this > document (ending February 5, 2021). George Michaelson has agreed to > shepherd this document through the last-call and IESG processes. > > Please reply with your comments by Feb 5, 2021. Thanks.
I've read the draft and labored to the implement various moving parts described in the draft in the real world. I'll summarize the various implementation aspects and provide POSIX-y CLI examples. TL;DR: READY FOR PUBLICATION Finding the Geofeed =================== mechanism #1: 'native attribute' Internet Routing Registry daemon (IRRd) version 4 supports 'geofeed:' RPSL attributes natively: https://github.com/irrdnet/irrd/pull/404/files mechanism #2: 'overloading remarks: field' As the RIPE NCC WHOIS Server does not yet support the 'geofeed:', I opted to use the "remarks: Geofeed ${URI}" workaround, gotta love permission-less innovation! :-). One can query the RIPE NCC database using WHOIS to find the reference (or plow through https://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz) $ whois -h whois.ripe.net -- '-rBGTinet6num 2001:67c:208c::/48' \ | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv One can download the linked Geofeed file for inspection: $ ftp -MV https://sobornost.net/geofeed.csv $ ls -al geofeed.csv -rw-r--r-- 1 job wheel 2120 Feb 1 17:31 geofeed.csv Authenticating the Geofeed data =============================== The uncommented section of the file conforms to RFC 8805: $ head -1 geofeed.csv | tee geofeed_tbs 2001:67c:208c::/48,NL,NL-NH,Amsterdam The commented out section of the geofeed.csv file contains a base64 encoded detached CMS signature (DER) using the 'id-ct-geofeedCSVwithCRLF' content type, a sha256 message digest, and can be verified against a public CA. The CA can be reached through the RIPE NCC RPKI Trust Anchor and has 2001:67c:208c::/48 as subordinate resource. Extract DER encoded signature: $ cat geofeed.csv | sed '1,2d;$d' | base64 -d > signature.der Extract the EE certificate (in PEM format) from the CMS envelope: $ openssl cms -verify -noverify -in signature.der -inform DER \ -certsout ee.pem 2>/dev/zero Inspect the EE certificate to see which authority signed it: $ openssl x509 -in ee.pem -noout -ext sbgp-ipAddrBlock,authorityInfoAccess sbgp-ipAddrBlock: critical IPv6: 2001:67c:208c::/48 Authority Information Access: CA Issuers - URI:rsync://rpki.ripe.net/repository/DEFAULT/LMq8Kl3LkWGqticaaLl6IAGSsJ4.cer A validated RPKI cache on the local filesystem can be constructed using a utility like OpenBSD's rpki-client (https://www.rpki-client.org). Copy the CA certificate from the validated cache, and convert it to PEM format: $ openssl x509 \ -in /var/cache/rpki-client/rpki.ripe.net/repository/DEFAULT/LMq8Kl3LkWGqticaaLl6IAGSsJ4.cer \ -inform DER -out ca.pem Finally, verify the signature over the Geofeed content against the authority: $ openssl cms -verify -content geofeed_tbs \ -in signature.der -inform DER -CAfile ca.pem 2001:67c:208c::/48,NL,NL-NH,Amsterdam Verification successful Conclusion ========== I believe with the above I've independently implemented all aspects of draft-ietf-opsawg-finding-geofeeds in one way or another, demonstrating the described procedures are correct, verifyable, and somewhat understandable. The prefix I used is a real-world example, allowing others to inspect the referenced inet6num RPSL object, the associated Geofeed file, including the authentication aspect. Appendix A was very helpful. Kind regards, Job _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
