Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

Tim Bruijnzeels <tim@ripe.net> Tue, 05 August 2014 19:12 UTC

Return-Path: <tim@ripe.net>
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 69F7E1B2B33 for <sidr@ietfa.amsl.com>; Tue, 5 Aug 2014 12:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 VaD2X5A1gCvW for <sidr@ietfa.amsl.com>; Tue, 5 Aug 2014 12:12:44 -0700 (PDT)
Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA12F1B2B29 for <sidr@ietf.org>; Tue, 5 Aug 2014 12:10:58 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1XEk8N-0000yt-3U; Tue, 05 Aug 2014 21:10:56 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-81.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1XEk8M-0004SQ-Rt; Tue, 05 Aug 2014 21:10:54 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="windows-1252"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <BEF3BAD0-7180-4433-B0FB-75CD83853D82@tislabs.com>
Date: Tue, 05 Aug 2014 21:10:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EF180A72-B061-49BC-8FCB-3CC78CA35F7E@ripe.net>
References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <BB01407F-A226-4531-9FDD-50E1B0A238F0@ripe.net> <53D151F0.80808@bbn.com> <C838412C-D16C-4C88-B022-85484789444A@ripe.net> <53D178A6.7060502@bbn.com> <CFF7CDF2.4AB4B%bje@apnic.net> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <CA+z-_EUXA0TWDqHV-9sFbgS2vyXiKE9EKBae6K0eihuhKTsm2A@mail.gmail.com> <53DAA101.8020305@bbn.com> <D00562F3.2A8A4%wesley.george@twcable.com> <BEF3BAD0-7180-4433-B0FB-75CD83853D82@tislabs.com>
To: Sandra Murphy <sandy@tislabs.com>
X-Mailer: Apple Mail (2.1878.6)
X-RIPE-Spam-Level: ---
X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719721b45da262e97c520db3a69d6c89579
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/DYZdEG17MVJZ3ZGy40sMcAnBRpE
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt
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: Tue, 05 Aug 2014 19:12:47 -0000

Hi all,

On 04 Aug 2014, at 23:47, Sandra Murphy <sandy@tislabs.com> wrote:

> speaking as a regular ol' member
> 
> On Aug 4, 2014, at 4:42 PM, "George, Wes" <wesley.george@twcable.com> wrote:
> 
>> Late to the discussion because I needed to have cycles to read and think
>> about this draft...
>> 
>> 
>> On 7/31/14, 4:03 PM, "Stephen Kent" <kent@bbn.com> wrote:
>> 
> 
>> This is probably true for routes that transition from
>> Valid to Unknown, but not if they are actually found to be Invalid, which
>> is what I understand would be the result of the problem discussed in this
>> draft - invalid certs = invalid routes. 
> 
> Well….
> 
> invalid EE certs = invalid ROA (for the most part - there's operational consideration about not removing an EE cert if a repository is unavailable, I suppose)
> 
> An invalid ROA does not necessarily mean an invalid route.
> 
> If there is no other covering ROA, then a BGP route for that prefix becomes unknown, as Terry pointed out.
> 
> If there is another ROA which covers the same prefix, then a route may be invalid -- if no covering ROA authorizes the ASN that the invalidated ROA mentions.


I think we are dealing with a low-risk, but high-impact scenario here.

Arguments have been made to depict this as a virtually-no-risk and low-impact problem, but I am not convinced. 

I want to reduce the impact because low-risk, low-impact is a much better place to be.. I believe this is possible without any serious adverse effects.


With regards to impact:
=======================

= Origin validation:

Indeed: routes would (almost certainly*) go from Valid to Unknown. But, what are we trying to achieve here by this whole origin validation thing? Valid is preferred over Unknown, why else would we bother with this stuff in the first place? Sure, being pushed to Invalid is much worse, but a complete failure of origin validation for a large part of the internet (e.g. a whole RIR region) still counts as a high impact event in my book.

*: If a valid ROA exist through another certificate chain then routes could become Invalid. This scenario is less likely to happen by accident, because the parent would have to issue the same resource to more than one child certificate.

= Path validation:

For path validation it was mentioned that there is no ‘unknown’ state. And I am not sure if it’s even possible to differentiate here between ‘Invalid’ vs ‘Unknown’. I expect that the difference would be: knowing that that a path has been tampered with (key known, signature invalid) vs not being able to verify (unknown key). This looks attractive, but I think it opens an easy attack to just sign with a random key and the path is suddenly ‘unknown’ and not ‘invalid’.. Maybe I am missing something, if someone has an idea about how this could work that would be great. Unknown is still a better place to be than invalid, but only if there is a real difference between the two.

So, all in all, I still believe that this *is* a high impact problem.

The solution the authors have been suggesting to this problem consists of *limiting* the impact to just the affected resources. If we had that we could turn this problem into a low-risk, and much-lower-impact problem.


With regards to risk:
=====================

Low risk does not equal no risk. And combined with high impact this is problematic.

While all RIRs and other responsible CAs are using precautions, there are many moving parts and problems can happen. Bugs in software, human error, timing issues in publishing parent and child certificates can all result in inconsistencies between the certificate issued and published by the parent at a point in time, and what the child believes they have.

Currently RIRs maintain their own TAs, and this puts them in a position where they have full control and knowledge of when changes occur, so currently the risk these inconsistencies is fairly limited (but not absent). In case this changes the risk increases. And because it’s child certificate that ends up being rejected the immediate impact is on the party that has the least control over this.


Tim