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

Tim Bruijnzeels <> Tue, 12 June 2012 08:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0A2C21F85A3 for <>; Tue, 12 Jun 2012 01:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ucnzg0a7ifZc for <>; Tue, 12 Jun 2012 01:31:26 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1342]) by (Postfix) with ESMTP id BFA5821F8510 for <>; Tue, 12 Jun 2012 01:31:25 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <>) id 1SeMVV-0006Rk-31; Tue, 12 Jun 2012 10:31:23 +0200
Received: from ([] by with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <>) 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 <>
In-Reply-To: <>
Date: Tue, 12 Jun 2012 10:31:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Murphy, Sandra" <>
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: "" <>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jun 2012 08:31:26 -0000


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


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 ( 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

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.


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.