Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@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 In-Reply-To: Date: Thu, 30 Apr 2015 00:24:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" , David Mandelberg Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 22:24:57 -0000 On 29 Apr 2015, at 23:47, Sriram, Kotikalapudi = 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.) =20 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=