Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06

Tim Bruijnzeels <tim@ripe.net> Tue, 12 June 2012 08:31 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A2C21F85A3 for <sidr@ietfa.amsl.com>; Tue, 12 Jun 2012 01:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucnzg0a7ifZc for <sidr@ietfa.amsl.com>; Tue, 12 Jun 2012 01:31:26 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id BFA5821F8510 for <sidr@ietf.org>; Tue, 12 Jun 2012 01:31:25 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SeMVV-0006Rk-31; Tue, 12 Jun 2012 10:31:23 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-142.ripe.net) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SeMVU-0003BK-Jw; Tue, 12 Jun 2012 10:31:20 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F1340A@Hermes.columbia.ads.sparta.com>
Date: Tue, 12 Jun 2012 10:31:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AFAF174A-F3D0-4D5C-A375-D7C8D283E5CE@ripe.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F1340A@Hermes.columbia.ads.sparta.com>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
X-Mailer: Apple Mail (2.1084)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120612 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_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: 784d7acfe6559f2a0b602ec6519a071988437e8b36b5d2ee993bed2014ec186b
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Jun 2012 08:31:26 -0000

Hi,

On 2 Jun 2012, at 01:00, Murphy, Sandra wrote:
> The authors have stated that they believe that draft-ietf-sidr-pfx-validate-06 "BGP Prefix Origin Validation" is ready for a working group last call.


Prefix validate assumes full knowledge of all applicable ROAs (or other sources of information if they are used) and I believe this should be stated more strongly.

The security considerations section addresses the possibility of a malicious attacker tampering with the database that is used for validation. It does not address the possibility of a database becoming incomplete for other reasons. 

In particular I am worried about repositories:
1- being completely unreachable for a prolonged time
2- being inconsistent


@1:

A relying party tool may choose to use old information if a repository can not be reached. This assumes that the RP has this old data, and it will only work for a while. There is some unclarity what to do if the manifest goes stale (next update time in the past) vs a manifest EE certificate expiring (http://tools.ietf.org/html/rfc6486#section-5.1 dictates a one-time use EE cert should match this).

In particular consider this case:

Parent CA:
- has cert for 10/8
- ROA for 10.0/16 AS A
- signed cert to child for 10.0.0.0/22

Child CA:
- publication point is unreachable, old data expired (new RP instances unaware even)

There is a very real possibility that the parent's ROA invalidates the child announcements.

I believe that the only reasonable, automated, action an RP can take in this case is to disregard any INRs mentioned on the child CA's cert whose pub point is unreachable.



@2:

With inconsistent I mean the following cases:
- hash invalid for ROA
- missing ROA
- surplus ROA

The RP has a very tough time deciding what to do:
- the invalid ROA could be a publication error, or it could be that another ROA with the same name was intended to be published, but we didn't see it
- a missing ROA could validate an announcement that is now considered invalid because of another ROA
- the surplus ROA's intention is unclear, it could be that the CA forgot to delete and revoke this, and it's invalidating announcement(s)

I understand that the authors intended manifests as a replay detection mechanism and most of the wording regarding validation uses SHOULDs and 'local policy'. However, I believe that this is not strong enough for pfx-validate. Local policy sounds very reasonable when in doubt, but I have no faith that operators will have enough knowledge to make educated decisions in all these cases. By and large I expect that operators will go with the *default* local policy decisions that are implemented in the RP tool they use.

In short I think that pfx-validate's requirement for full knowledge dictate that there MUST be a valid manifest listing the ROAs the CA intended to publish, they MUST all be present, all be valid, and no additional ROAs for the publication point can be considered.