IETF Logo Mail Archive

Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

Iljitsch van Beijnum <iljitsch@muada.com> Wed, 29 April 2015 22:24 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7392C1A885C; Wed, 29 Apr 2015 15:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 jPaLQ_GIita8; Wed, 29 Apr 2015 15:24:55 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735D51A8855; Wed, 29 Apr 2015 15:24:55 -0700 (PDT)
Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:995e:8e8e:2b66:a875] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3TMOdtq011768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2015 00:24:40 +0200 (CEST) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <CY1PR09MB079352552ED82496B5A4513D84D70@CY1PR09MB0793.namprd09.prod.outlook.com>
Date: Thu, 30 Apr 2015 00:24:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1FBD55B-D019-498E-BDE8-8ABE2A4BC98F@muada.com>
References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <ECDAD8F2-1C27-4494-887C-59280D7FF973@muada.com> <EF4348D391D0334996EE9681630C83F02D173BEB@xmb-rcd-x02.cisco.com> <B1EDF7B6-1E42-440E-BD3F-29723AD7E4A4@muada.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> <CY1PR09MB079302CC52C7791F3C0C512984D70@CY1PR09MB0793.namprd09.prod.outlook.com> <CF9FE7BA-C934-401C-B2F4-0CE4AF062ECC@muada.com> <CY1PR09MB079352552ED82496B5A4513D84D70@CY1PR09MB0793.namprd09.prod.outlook.com>
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/shIMrwavuzsfMjrG6djeviGxEgY>
Cc: "idr@ietf.org" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, David Mandelberg <david@mandelberg.org>
Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2015 22:24:57 -0000

On 29 Apr 2015, at 23:47, Sriram, Kotikalapudi <kotikalapudi.sriram@nist.gov> wrote:

> The above two BCP steps, if followed, will help prevent "couldn't validate because of certificate lifetime".

Of course, most of the time this would happen correctly. People aren't stupid. But experience with HTTPS has shown that expired certificates can't be prevented 100%, and with routing the results are much more severe than with the web, as the user can't decide to go ahead anyway. The user wouldn't even know what happened. And fixing the problem may not be possible because of the unreachability caused by the problem.

> Second:
> The operational BCP can also say:
> Allow a certain grace period before you act on the update that became 'Not Valid' due to cert expiry.
> (Earlier Sandy also mentioned this.)  

Ok. So what do you propose?

That a path with signatures based on expired certificates remains "valid" for some additional grace period? Then you simply postpone the problem by that period.

Or should operators have a way to differentiate between paths that are actually invalid and paths that are merely affected by expired certificates? In that case we are saying the same thing.

It might even be useful to have valid / expired-but-otherwise-valid / unknown / invalid rather than valid / unknown / invalid. Or maybe valid-algo1 / valid-algo2 / expired-but-otherwise-valid / unknown / invalid, so I can prefer paths protected with the strongest hashing algorithm over paths protected with a weaker algorithm and those over paths protected with expired certificates and those over paths not protected by BGPsec. (IMO invalid paths should not be allowed at all.)

Iljitsch

v2.23.0 | Report a Bug | By Email