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

Iljitsch van Beijnum <iljitsch@muada.com> Tue, 28 April 2015 19:21 UTC

Return-Path: <iljitsch@muada.com>
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 D3EFB1A0250; Tue, 28 Apr 2015 12:21:48 -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 Aiwj6SVOaPb7; Tue, 28 Apr 2015 12:21:47 -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 03DCC1A01BA; Tue, 28 Apr 2015 12:21:46 -0700 (PDT)
Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3SJLKr0071532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 21:21:21 +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: <EF4348D391D0334996EE9681630C83F02D173BEB@xmb-rcd-x02.cisco.com>
Date: Tue, 28 Apr 2015 21:21:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1EDF7B6-1E42-440E-BD3F-29723AD7E4A4@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>
To: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/zAY_TlMnFb1rItEqJ0G-BXVrdLc>
Cc: "idr@ietf.org wg" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, "ggm@apnic.net" <ggm@apnic.net>
Subject: Re: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] 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 <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2015 19:21:49 -0000

On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:

> It is not an implementation choice, it is by design. If a signed object does not validate (based on whatever reason not just expiration), it is like if did not existed. 

No...

Suppose:

ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430

BGP table 29 april:

193.0.0.0/21   3333 -> valid
193.0.0.0/21   4444 -> invalid
193.0.7.0/24   3333 -> invalid
192.0.0.0/16   5555 -> unknown

But, two days later, after the ROA expires, do we have this:

193.0.0.0/21   3333 -> unknown
193.0.0.0/21   4444 -> unknown
193.0.7.0/24   3333 -> unknown
192.0.0.0/16   5555 -> unknown

or this:

193.0.0.0/21   3333 -> invalid
193.0.0.0/21   4444 -> invalid
193.0.7.0/24   3333 -> invalid
192.0.0.0/16   5555 -> unknown

?

You seem to be saying the second, but that wouldn't work, as a simple mistake would make AS 3333 unreachable. And since you need to connect to the internet in order to get a new certificate/ROA so you can connect to the internet...

The NANOG link I posted says it's the first case, which would be much more workable in practice: in that case, if a certificate expires before a new one is installed, you lose security but not connectivity. As we've successfully run BGP for 25 years without security, that's bad, but preferable to being unreachable.

Note also that the approach suggested in RFC 6483 and Cisco and Juniper documentation, where valid > unknown > invalid is not workable because then can still have traffic flow towards more specific prefixes even though they're invalid and have a very low local preference. The nice thing about RPKI is that you can deploy it TODAY if you filter invalids with the huge upside that you get rid of unauthorized more specifics, incurring only the very small risk that someone creates ROAs that conflict with their advertisements.

But the real issue is that this isn't written down anywhere as far as I can tell, so we're dependent on implementers all independently coming up with the preferred way to handle this. That's never good business for a standards organization.