Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds

From: Job Snijders <[email-masked]>
Date: Mon, 1 Feb 2021 20:16:40 +0100

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Feb 2021 10:26:53 -0800

> Authenticating the Geofeed data

folk trying to verify this are whining about some missing code

randy

---

From: Job Snijders <[email-masked]>
Date: Tue, 2 Feb 2021 19:55:30 +0100

Hi Randy,

> folk trying to verify this are whining about some missing code

I'm not entirely sure what 'missing code' you are referring to. On
Debian Bullseye the required software can be installed using:

    $ sudo apt install openssl rpki-client

Pre-build binary packages exist for redhat, fedora, centos, gentoo,
freebsd, and ubuntu. See https://www.rpki-client.org/ +
https://www.openssl.org/ for portable source code.

The default installation of OpenBSD already contains all required tools
to perform the verification steps I described in my previous message.

The signature was produced through proprietary means, but for the
purpose of validating the signature & interopability testing that
shouldn't matter...  right?

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Feb 2021 14:33:54 -0800

> shouldn't matter...  right?

unless you are a security person and lived through trojans such as
dual-ec.  extension of kerckhoffs's principle.

randy

---

From: Job Snijders <[email-masked]>
Date: Wed, 3 Feb 2021 03:25:45 +0100

Dear Randy, working group,

It appears to me you really wanted to ask 'how the heck did you do it???'

*** warning: operating a CA is real work, do NOT follow the below ***

I declared my signing operation 'proprietary' because I can't recommend
it as a 'recipe'. I prefer to promote man pages over howtos; especially
when signing operators need to walk the path towards production
environment.

My objective in sharing a real-world example @ 2001:67c:208c::/48 is to
facilitate the 'draft-ietf-opsawg-finding-geofeeds' effort. I imagine
publishing a publicly verifable real-world example helps validator
implementers. Validators ofcourse should assume extreme hostile input.

My show case was generated without any assistance or communication with
the authors of the draft. In doing so, hopefully proving (or disproving)
the draft is readable and understandable, so that implementers can
produce similar results.

As you asked how exactly the 'kroket' is made....

> dual-ec.  extension of kerckhoffs's principle.

I used modern versions of libressl and openssl to generate the EE cert
and the signature.

    $ openssl cms -sign \
        -econtent_type 1.2.840.113549.1.9.16.1.47 \
        -nosmimecap \
        -md sha256 \
        -signer ee.cert \
        -inkey ee.key \
        -in geofeed.csv \
        -outform DER \
        -out signature.der

The EE cert was created with a CSR and a lengthy .cnf file. The
'1.2.840.113549.1.9.16.1.47' string can be replaced with a text string
after OpenSSL merges in https://github.com/openssl/openssl/pull/14050
The 'free, functional, secure, and mostly compatible public-API'
LibreSSL project appears comfortable adding the OID based on just the
IANA registry.

Kind regards,

Job

---

From: George Michaelson <[email-masked]>
Date: Wed, 3 Feb 2021 13:10:39 +1000

I think this is useful.

It shows how tools that operations people are familiar with can be
used to improve the trust in the feed.

Nice work Job!

-G

On Wed, Feb 3, 2021 at 12:25 PM Job Snijders
<job=[email-masked]> wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Feb 2021 21:18:23 -0800

hi job,

as ggm said, really appreciate your showing the tech can be done.

openssl is conservative, which has good and bad effects.

randy

---

From: Massimo Candela <[email-masked]>
Date: Wed, 3 Feb 2021 21:00:09 +0100

> Conclusion

Hi Job,

I have reproduced your steps and verified your geofeed.
Thanks for this demo and for your support!

Ciao,
Massimo

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 8 Feb 2021 15:46:17 +0000

Thanks to all the working group members that replied on this last call. 
There were some comments that will lead to document changes, but overall
there seems to be consensus that this work should progress.  Thanks to
Job Snijders that shared a working implementation of this work.

There is one outstanding IPR disclosure reply from Russ. No directorate
reviews have yet to come in, but I am told that RTG should have a reply
by the end of this week.

Authors, if you wish to revise the draft now, please go ahead.  George,
you can start on your shepherd write-up, and hopefully we can move this
onto the IESG's plate by early next week.

Joe

On 1/22/21 16:44, Joe Clarke (jclarke) wrote:
> Joe

---

From: Randy Bush <[email-masked]>
Date: Mon, 08 Feb 2021 13:05:27 -0800

> There were some comments that will lead to document changes

commenters, please check -02

and thanks all

randy

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Feb 2021 21:12:12 -0000

Thanks Randy,

I'm as happy as I'm likely to get.

Adrian

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of Randy Bush
Sent: 08 February 2021 21:05
To: Joe Clarke (jclarke) <jclarke=[email-masked]>
Cc: [email-masked]
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds

and thanks all

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 08 Feb 2021 14:46:45 -0800

-02 was published.  but, due to a merge miscommunication, it left off a
couple of acknowledgments.  it also misspelled Acknowledgments :)

i'll not push -03 until after comments of substance are incorproated,
assuming no one objects.

randy

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 9 Feb 2021 14:06:30 +0000

Seems reasonable.  I'm hoping we get some RTGDIR comments this week.

Joe

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Feb 2021 15:29:16 -0800

now that last call is over, it's time to make trouble by requesting to
add a hack.  ggm, doc shepherd, has this idea about hierarchic signing
which would affect this doc by adding

   If an inetnum: A points to a geofeed file which is signed per
   Section 4, then a geofeed file pointed to by inetnum: B which is
   covered by A (i.e., B is for a more specific prefix of A) the
   geofeed file pointed to by inetnum: B SHOULD also be signed.  If not,
   then the consumer should be suspicious of data within the geofeed
   file pointed to by B.

to 5.  Operational Considerations

would anyone care to comment, object, maybe even support?

randy

---

From: Erik Kline <[email-masked]>
Date: Wed, 17 Feb 2021 16:20:56 -0800

> would anyone care to comment, object, maybe even support?

I agree that this proposed addition seems to highlight and may address
a potential security issue.

But if a lookup process was interested in finding a geofeed for an IP
address within B, would it have any reason or automated means to
backtrack and lookup knowledge of the signed geofeed for A?  Do
inetnum lookups return all superprefix inetnums as well?  (asking for
a friend)

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Feb 2021 16:25:27 -0800

> inetnum lookups return all superprefix inetnums as well?  (asking for

whoops!

---

From: George Michaelson <[email-masked]>
Date: Thu, 18 Feb 2021 10:39:50 +1000

Thats a good question. Whois lookups CAN ask for superior covering
blocks. Its in the protocol to do it (flags) in the port 43 query. I
don't think its normal.

This is the problem with data services which push to the most specific
record (and, in Whois, many exist) and inclusion of signing, which
strongly depends on chain verification which automatically includes
the parents as necessary components of the proof. One method you punch
to the edge. The other, you get the path along with the edge.

It's about making a decision. How do you guide what people do?

(shepherd hat) I didn't mean to perturb a process in WGLC. I think
this is worth discussing, I am unsure it has to be said in this draft,
I don't object to people working it out if it makes sense. It is
actually kind-of a side observation in the shepherd write-up as-is.
-G

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Feb 2021 16:46:08 -0800

i have reverted the doc in my emacs buffer.  -03 stands

randy