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

Tim Bruijnzeels <tim@ripe.net> Sat, 16 June 2012 08:43 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 232EE21F8597 for <sidr@ietfa.amsl.com>; Sat, 16 Jun 2012 01:43:29 -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 s-DA+W+Ntcis for <sidr@ietfa.amsl.com>; Sat, 16 Jun 2012 01:43:28 -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 DBFEF21F8593 for <sidr@ietf.org>; Sat, 16 Jun 2012 01:43:27 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SfobK-0007FS-MT; Sat, 16 Jun 2012 10:43:24 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-143.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SfobK-0000B1-6U; Sat, 16 Jun 2012 10:43:22 +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: <AFAF174A-F3D0-4D5C-A375-D7C8D283E5CE@ripe.net>
Date: Sat, 16 Jun 2012 10:43:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <27839AC4-30E4-4C02-A64E-EAAC6F8B58D4@ripe.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F1340A@Hermes.columbia.ads.sparta.com> <AFAF174A-F3D0-4D5C-A375-D7C8D283E5CE@ripe.net>
To: Tim Bruijnzeels <tim@ripe.net>
X-Mailer: Apple Mail (2.1084)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120616 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: 784d7acfe6559f2a0b602ec6519a07193cce04d62fdcfa005b4a402fbc60914c
Cc: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "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: Sat, 16 Jun 2012 08:43:29 -0000

Hi,

Please allow me to clarify my earlier comments.

On 12 Jun 2012, at 10:31, Tim Bruijnzeels wrote:

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

This is the main point I wanted to make. I believe this can be easily addressed by just stating the requirement in this document. Perhaps something along these lines at the end of the first paragraph in the security consideration section:

"Additional or missing records resulting from retrieval and/or validation errors can lead to the same problems."

The following was just a discussion on how RPs can mitigate these problems. But.. perhaps this is better addressed in a separate BCP, or future work on specifications related to the repository and retrieval/validation by RPs.

If the WG can agree with this then I can support last call..


> 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.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr