Re: [Sidrops] 6486bis: referenced object validation

Lukas Tribus <lukas@ltri.eu> Fri, 04 December 2020 20:46 UTC

Return-Path: <lukas@ltri.eu>
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 05BC33A0ECB for <sidrops@ietfa.amsl.com>; Fri, 4 Dec 2020 12:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ltri.eu
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 vqS0sHyxGhly for <sidrops@ietfa.amsl.com>; Fri, 4 Dec 2020 12:46:19 -0800 (PST)
Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601B53A0C37 for <sidrops@ietf.org>; Fri, 4 Dec 2020 12:46:19 -0800 (PST)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Cnl9P5C48zQlLR for <sidrops@ietf.org>; Fri, 4 Dec 2020 21:46:17 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ltri.eu; s=MBO0001; t=1607114775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KZC7KCXfWe9DKxUsg0vDfaB7U94jt8JmSfN5cL6jqIs=; b=hoSmqH8eoTCZLEdaleRvcPkcmbZUlO3clPSGV29jn86llfhurLVunfPmOka259NWhTOgpQ It27fhepJshoQYCAROveBnZBnU/FQ87E7tn75lQb2yTcWjGz/M1PIZdLSI+pVy45BHDQiX 3XJ9OvzVAfTZRxvoFENasvNb7BnkvaVgfGeIOzXRwhEvMBShZzPs1U/P0qQJBAY/MILY5V CyC1/7GE1vnWHQLPiE0HY3XcEpk+08iGQBe5nrwiRMlcYn5C+CdH8CTIRr+VdffEf6VQTR 3926EYdor3Fpg1LL7FZVQl6vchezSo8xM8LW0zqjblDCM9Fr3wmHMqVM8g90gA==
Received: from smtp2.mailbox.org ([80.241.60.241]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id iq1LxPk1m6zN for <sidrops@ietf.org>; Fri, 4 Dec 2020 21:46:13 +0100 (CET)
Received: by mail-io1-f51.google.com with SMTP id r9so7119784ioo.7 for <sidrops@ietf.org>; Fri, 04 Dec 2020 12:46:13 -0800 (PST)
X-Gm-Message-State: AOAM531vU/mQ5hQb4o8BERbmh1kbcFm+plNRphMwc8ICyv99kspg+zQO qPwDXSGW6v3eQ+NlJlymFDt60kMhqdADHNnHJf0=
X-Google-Smtp-Source: ABdhPJyHGJqDxE+u4g6/Wali/KNQfhrcd5BkwDZ+YPWFVQZs49oxD4hOvkbb2UZFf359nGC/N0JaaxGh5tDgrog9u5Y=
X-Received: by 2002:a02:a419:: with SMTP id c25mr8611864jal.91.1607114772063; Fri, 04 Dec 2020 12:46:12 -0800 (PST)
MIME-Version: 1.0
References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <X8oSBlR1pDhX83nH@bench.sobornost.net> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <X8on7A4R63HYUnpz@bench.sobornost.net> <d518f9de-850c-ad10-49a5-1eee4c85fa6b@NLnetLabs.nl> <X8pJoTEUDwpE6iIi@bench.sobornost.net> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl>
In-Reply-To: <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl>
From: Lukas Tribus <lukas@ltri.eu>
Date: Fri, 4 Dec 2020 21:46:00 +0100
X-Gmail-Original-Message-ID: <CACC_My9VXvVVB8DucXbnwfKfXo9bq47di6Q_+R2YOHgHF+OYJQ@mail.gmail.com>
Message-ID: <CACC_My9VXvVVB8DucXbnwfKfXo9bq47di6Q_+R2YOHgHF+OYJQ@mail.gmail.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: Job Snijders <job@ntt.net>, Benno Overeinder <benno@nlnetlabs.nl>, SIDR Operations WG <sidrops@ietf.org>, Martin Hoffmann <martin@opennetlabs.com>, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-MBO-SPAM-Probability:
X-Rspamd-Score: -7.47 / 15.00 / 15.00
X-Rspamd-Queue-Id: 71C4B17B3
X-Rspamd-UID: e2ff66
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/6rNqx2LREBFhXbJNbpZqH_5ViOw>
Subject: Re: [Sidrops] 6486bis: referenced object validation
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: Fri, 04 Dec 2020 20:46:21 -0000

Hello!


On Fri, 4 Dec 2020 at 16:58, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
> On 6486 in particular there was a strong desire communicated by operators
> that RPs behave the *same* way.

If I recall correctly, I expressed this desire, yes.

This was based on my gross underestimation of the complexities of the
RPKI repository system and also a lack of understanding of how routers
will handle multiple RTR servers at the time.

As a network operator, I like the fact that BGP implementations across
vendors, given the same/similar parameters, select the same best path.
This means I can replace vendor X with vendor Y in location Z and keep
the rest of the network as is, without routing loops. However
different VRP outputs from RP's do not cause routing loops in networks
(when deployed correctly). Apart from routing loops in the BGP
analogy, same exact VRP output means that I don't have to think about
what happens if different RP software disagrees, which I can
appreciate. However the RPKI repository system is just too complex and
has too many variables.

In the WebPKI world, although TLS is standardized, TLS clients will
behave differently. Firefox is actively querying OCSP servers, Chrome
will never do that and will wait for Google to push CRL-sets to the
browser. Implementation choices vary widely. If the TLS RFC's would go
into such details like specifying whether Firefox or Chrome is "right"
(should a browser actively query OSCP server and what about walled
gardens [...]), that would probably make RFC ratifications take a
*very long* time (too long to keep up, while the real world moves on)
and defeat it's entire purpose. And how would this impact something
like 1/n-1 record splitting (the workaround for the BEAST
vulnerability, which all browsers implemented after Chrome made the
first step forward [1])?

While the same exact VRP output from different RP's would be *nice to
have* for us network operators, I fail to see how this is actually
necessary. It certainly is more convenient to not have to think about
those mismatches, that's the reason why I advocated for this, but that
is not a luxury we can afford.

This is why I now believe expecting the same VRP output from different
RP's is an unrealistic goal and actually harmful. A software
implementer must feel free to implement fixes for important
operational issues as they see fit.


Best regards,

lukas

[1] https://www.imperialviolet.org/2012/01/15/beastfollowup.html
















Which is why we were hesitant to implement the changes suggested by
you in the GH issue. In fact we even agree with the approach in the
issue. But it's different from where the -bis text is headed until
now. We felt that the desire for universal behaviour (-bis) outweighed
the rush to make a quick change here. You are welcome to disagree with
that assessment, but understand that there was well intended reasoning
behind it.
>
> > You mentioned some kind of testbed, indeed it would be wonderful if we
> > can easily reproduce states of the RPKI and allow implementers to
> > provide annotations on why software (versions) behaves in a certain
> > way. The December 1st, 2020 case is definitely one I'd add to the
> > testbed archive.
>
> It would be. I think this is an effort in itself. Do you have a proposal in mind?
>
> >
> >>> The real goal is to keep the network running, where in this context
> >>> our role is to create software for network operators for them to
> >>> securely validate the wishes of the Internet number resource
> >>> holders.
> >>
> >> Agree to that!
> >>
> >> Let's keep the good spirit of collaboration and learning together.
> >
> > For sure!
>
>
> For sure!
>
> Tim
>
> >
> > Kind regards,
> >
> > Job
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops