Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

Tim Bruijnzeels <tim@ripe.net> Thu, 05 October 2017 12:27 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 4BF88126DD9; Thu, 5 Oct 2017 05:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.499
X-Spam-Level:
X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] 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 Mue3bEYPwVJw; Thu, 5 Oct 2017 05:27:46 -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 EE070124239; Thu, 5 Oct 2017 05:27:45 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1e05Ff-0002Xa-Mg; Thu, 05 Oct 2017 14:27:44 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-62.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1e05Ff-0008D2-J9; Thu, 05 Oct 2017 14:27:43 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <CAL9jLaYXK4vLGtNgqs_ofPmEBez=AmrgD+dPwUhG-=A_NHokTg@mail.gmail.com>
Date: Thu, 5 Oct 2017 14:27:43 +0200
Cc: "sidr@ietf.org" <sidr@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, sidr-ads@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <470CB4A7-8639-4889-AF51-C0B8B4CCA4C9@ripe.net>
References: <CAL9jLaYXK4vLGtNgqs_ofPmEBez=AmrgD+dPwUhG-=A_NHokTg@mail.gmail.com>
To: Christopher Morrow <christopher.morrow@gmail.com>
X-Mailer: Apple Mail (2.3273)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719f2d52c13cd83b8ab12b129daed830337
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/_elCF2ZuTT_m_8RjjtKq8hROzFQ>
Subject: Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 05 Oct 2017 12:27:47 -0000

Hi,

This looks reasonable to me, but I can’t speak really to the router implementation - being neither a network operator nor a router vendor. As a CA operator I note that the draft is not restrictive about exactly how the RPKI CA gets the CSR, and the signed certificate is returned. That’s a good thing to me at this point, so I would say ship it. But I believe it would be good to keep this in mind in the sidr-ops WG - if this proves operationally difficult then it may be something to discuss further later.

Tim

> On 3 Oct 2017, at 05:14, Christopher Morrow <christopher.morrow@gmail.com> wrote:
> 
> WG Folk,
> I thought I had sent this note our previously, but... better late then never sent:
> 
> Please consider this the WGLC for:
>   https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-13
> 
> Abstract:
>   "BGPsec-speaking routers are provisioned with private keys in order to
>    sign BGPsec announcements.  The corresponding public keys are
>    published in the global Resource Public Key Infrastructure, enabling
>    verification of BGPsec messages.  This document describes two methods
>    of generating the public-private key-pairs: router-driven and
>    operator-driven."
> 
> Please send along comments/complaints/issues/kudos (to the authors), to the list and I'll see you all in ~14 or so days.
> 
> Thanks!
> -chris
> co-chair
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr