Re: [Sidrops] Example BGPSec Router certificate, and GBR for testing?

Job Snijders <job@ntt.net> Mon, 07 December 2020 17:51 UTC

Return-Path: <job@ntt.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F833A1632 for <sidrops@ietfa.amsl.com>; Mon, 7 Dec 2020 09:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADgJkz9o1Xws for <sidrops@ietfa.amsl.com>; Mon, 7 Dec 2020 09:51:11 -0800 (PST)
Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95FB3A162E for <sidrops@ietf.org>; Mon, 7 Dec 2020 09:51:11 -0800 (PST)
Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id EA415220376; Mon, 7 Dec 2020 17:51:09 +0000 (UTC)
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 20e41c72; Mon, 7 Dec 2020 17:51:05 +0000 (UTC)
Date: Mon, 7 Dec 2020 17:51:05 +0000
From: Job Snijders <job@ntt.net>
To: sidrops@ietf.org
Message-ID: <X85riY5zJoDwYCxJ@bench.sobornost.net>
References: <7058F38E-AB83-4209-823D-6A3B860711B6@nlnetlabs.nl> <X84y7FpLUJlNQxjZ@bench.sobornost.net> <39C631B2-0BEA-4833-96B3-83F1186DC4B6@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39C631B2-0BEA-4833-96B3-83F1186DC4B6@nlnetlabs.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/lwZ5Vxl3sDLIheuzonvsAXBAXhM>
Subject: Re: [Sidrops] Example BGPSec Router certificate, and GBR for testing?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2020 17:51:13 -0000

On Mon, Dec 07, 2020 at 03:06:47PM +0100, Someone wrote:
> Thanks! We noticed.
> 
> When we looked earlier it had the wrong vCard version, but it's useful
> to have this also in that state. My colleagues are already analysing
> it. We can report on it later.

Ah, good catch. Now fixed:

    $ rsync rsync://chloe.sobornost.net/rpki/Sobornost/LMrbiOIR4bDInnBEXLsY5MZ1q1U.gbr .
    $ openssl cms -verify -noverify -in LMrbiOIR4bDInnBEXLsY5MZ1q1U.gbr -inform der
    BEGIN:VCARD
    VERSION:4.0
    ADR:;;;Amsterdam;;;The Netherlands
    EMAIL:job@sobornost.net
    FN:Job Snijders
    N:;;;;
    ORG:Sobornost
    TEL:+31654942365
    END:VCARD
    Verification successful

Without pointing fingers to anyone...

It appears not yet all validators are able to handle the presence of
this valid, correct, signed data gracefully... In some networks my Very
Important route is now marked as 'not-found' in BGP routers instead of
'valid'.

Any CA could at any moment start publishing .gbr files, and it seems
some validators consider all objects on the manifest to be invalid
merely because they don't (yet?) support Ghostbuster Records.

While would be beneficial if all validators implement decoding RFC 6493
objects... something worse than 'lack of support' is going on: I
currently see some RPs 'choke' on the ghostbuster record and as a result
ignore adjacent .roa files (which I consider critical for Internet
routing).

The existence of validators which don't *at least ignore* object types
that are unknown is potentially is somewhat detrimental to the
deployment of new applications based on PKIX-RPKI.

To validate the *manifest*, at a high level a validator should perform
these steps:

    1) check if the manifest's EE certificate is valid, current, not-revoked
    2) check if each file listed on the manifest is present
    3) check if the hash of each file matches the hash on the manifest
    4) process each object according to the rules for that object (if
       the object type is supported, if the object type is not supported
       ignore the object)

So in the subsequent 'per object' validation (that follows after
manifest validation), an object like this Ghostbuster Record can of
course be ignored if the implementation does not support GBR files.

In summary: I posit that lack of support for a given object type is not
a great reason to 'throw out' all objects on a valid manifest.

Kind regards,

Job