Re: [sidr] revising Section 7.2 of RFC 6487

Tim Bruijnzeels <tim@ripe.net> Fri, 01 July 2016 11:51 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 674AE12B05A for <sidr@ietfa.amsl.com>; Fri, 1 Jul 2016 04:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 XcWc3EOlKJIh for <sidr@ietfa.amsl.com>; Fri, 1 Jul 2016 04:51:41 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 7F8D412B004 for <sidr@ietf.org>; Fri, 1 Jul 2016 04:51:41 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bIwyv-0002DL-As; Fri, 01 Jul 2016 13:51:38 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-49.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bIwyv-0006Fx-60; Fri, 01 Jul 2016 13:51:37 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <4C5B2CAA-58AC-4A12-8C30-03FA4CB42BB2@apnic.net>
Date: Fri, 1 Jul 2016 13:51:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D01CF6C8-54BA-4B1C-AEAB-4CA477960680@ripe.net>
References: <bc4f2d97-e858-c834-b8c1-241f1cb0ed3a@bbn.com> <F5A6EBD6-49A8-4FBB-8039-53B09F4E0B9E@apnic.net> <f989d80e-2538-8b02-fc65-7a2cbf6a57ca@bbn.com> <4C5B2CAA-58AC-4A12-8C30-03FA4CB42BB2@apnic.net>
To: Geoff Huston <gih@apnic.net>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: --------
X-RIPE-Spam-Report: Spam Total Points: -8.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4080]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e8d9b31671051aff9f8fab2ea1f8fbf7
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/aipph6Fw5nSBawhx6CyQZqDKHd4>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] revising Section 7.2 of RFC 6487
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 01 Jul 2016 11:51:43 -0000

Hi,

I have just submitted a -05 version of the document.

This version includes:
= minor clarifications and improvements to the English (thanks Steve)
= the text to replace all of RFC6487 section 7.2 suggested by Steve including Geoff's comment
= amended to reject over-claiming EE certificates so we only need to update 6487

I would like to ask the WG (BGPSec folk in particular) to have a look at the following text that I included on 'fate-sharing' ROAs and BGPSec certificates:

Note that ROAs [RFC6482] and BGPSec router (EE) certificates [I-D.ietf-sidr-bgpsec-pki-profiles] can contain multiple prefixes or ASNs respectively, and an over-claim of any of these would result in the ROA or BGPSec EE certificates being considered invalid. However, operators MAY issue separate ROAs or BGPSec router certificates to avoid this type of fate sharing.

For ROAs I think this is a feasible option. We can easily modify our code to issue a separate ROA for each prefix. I don't think this causes scaling issues. But can the same be said about router certificates? I guess the use case there is that the same key is used for different ASNs, right? Can one just issue separate certificates for each ASN?


And one other question to the working group. Is this something we need to talk about in Berlin again? I ask because we seem to be converging, and I don't want to claim speaking time if it's not needed.


Thanks,

Tim




> On 29 Jun 2016, at 04:07, Geoff Huston <gih@apnic.net> wrote:
> 
> Thanks! I am now very comfortable with your text on this.
> 
>   Geoff
> 
>> On 29 Jun 2016, at 3:39 AM, Stephen Kent <kent@bbn.com> wrote:
>> 
>> Geoff,
>> 
>> Thanks for reviewing the text.
>> 
>> I modified the text to change "current VRS-IP" to be "... the value of the VRS-IP computed for certificate x-1" as per your suggestion. I also made this change for the corresponding VRS-AS text.
>> 
>> I don't think we need to add a note about validation being performed "top down" since bullet B already says: "certificate '1' is a trust anchor"
>> 
>> Steve
>>> FWIW, I like this formulation Steve.
>>> 
>>> Possibly when you refer to "the current value of the VRS-IP” you may want to explicitly refer to the VRS-IP of certificate x-1 rather than “current”.
>>> 
>>> I also wonder if it is worth noting that the enumerated steps outlined here are intended to be performed “top down” - i.e. from a trust anchor to the certificate to be validated.
>>> 
>>> regards,
>>> 
>>>  Geoff
>>> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr