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

Pradosh Mohapatra <pmohapat@cisco.com> Sat, 16 June 2012 20:59 UTC

Return-Path: <pmohapat@cisco.com>
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 9EDC621F855A for <sidr@ietfa.amsl.com>; Sat, 16 Jun 2012 13:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 XhZABy1VYouq for <sidr@ietfa.amsl.com>; Sat, 16 Jun 2012 13:59:41 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BFF8321F8557 for <sidr@ietf.org>; Sat, 16 Jun 2012 13:59:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1484; q=dns/txt; s=iport; t=1339880381; x=1341089981; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1qKPMBo5pa2nrZyP4uAIDfxSpmLVPGEHLP5B/owNpOs=; b=BY2cZi14uK8WbyzmAHA0Ae9TAiF1GKkqgtyH3HrCmFzNa2/SSgdPTVON mxx5YJg9fKAhigwV4gmboXwHoK1dsKpl1j+Ik1jhY5AV6fi0zygiT/zQj I+Es6xn7ilFLRh8JjThCYEDFi5/+FNNNtwuirZdik9bRV27NMn4wIGGoI o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANry3E+rRDoG/2dsb2JhbABFtVOBB4IYAQEBAwESASc/EAtGVwY1h2QEmHSfEJETYAOIQoxijheBZoMAgTgj
X-IronPort-AV: E=Sophos;i="4.75,783,1330905600"; d="scan'208";a="49139994"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 16 Jun 2012 20:59:41 +0000
Received: from sjc-vpn6-1550.cisco.com (sjc-vpn6-1550.cisco.com [10.21.126.14]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5GKxfiJ006886; Sat, 16 Jun 2012 20:59:41 GMT
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Pradosh Mohapatra <pmohapat@cisco.com>
In-Reply-To: <27839AC4-30E4-4C02-A64E-EAAC6F8B58D4@ripe.net>
Date: Sat, 16 Jun 2012 13:59:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE0B25DE-6166-4A46-9435-3A58DAA51BC2@cisco.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F1340A@Hermes.columbia.ads.sparta.com> <AFAF174A-F3D0-4D5C-A375-D7C8D283E5CE@ripe.net> <27839AC4-30E4-4C02-A64E-EAAC6F8B58D4@ripe.net>
To: Tim Bruijnzeels <tim@ripe.net>
X-Mailer: Apple Mail (2.1278)
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 20:59:42 -0000

Hi Tim,


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


I do not agree this is a "security" issue. I am guessing you meant permanent/eventual inconsistencies between the local and global repositories (since transient inconsistencies will always be there). That kind of inconsistency is most certainly a (protocol) implementation error and has to be dealt with at that layer.

- Pradosh