Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)

Chris Morrow <morrowc@ops-netman.net> Wed, 11 April 2012 18:08 UTC

Return-Path: <morrowc@ops-netman.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 3471E11E80C5 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.183
X-Spam-Level:
X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315]
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 95z9QCcx6a3d for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:08:34 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 77A6F11E80BA for <sidr@ietf.org>; Wed, 11 Apr 2012 11:08:34 -0700 (PDT)
Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:baac:6fff:fe92:fb7a]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 955043200A1; Wed, 11 Apr 2012 18:08:32 +0000 (UTC)
Message-ID: <4F85C89D.3040307@ops-netman.net>
Date: Wed, 11 Apr 2012 14:08:29 -0400
From: Chris Morrow <morrowc@ops-netman.net>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Danny McPherson <danny@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net> <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com> <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net>
In-Reply-To: <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: sidr-chairs@tools.ietf.org, sidr wg <sidr@ietf.org>, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
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: Wed, 11 Apr 2012 18:08:35 -0000

On 04/11/2012 01:57 PM, Danny McPherson wrote:
> 
> 
>> I suppose, to me this looks like any other configuration thing you
>> do today on routers... beating the vendor over the head to support
>> sane (netconf? maybe?) methods for provisioning, is already done.
> 
> So how we onboard, update, or purge information from RPKI and sign

I think there are 2 things here:
  1) router-signing-cert (ee-cert?)
  2) rpki-digested-data (prefix + origin + cert-sig/etc)

they don't have to get to the router in the same way, do they? (I
suppose they COULD, but that isn't necessarily mandatory and isn't how
it's currently spec'd)

> stuff on n routers in z locations that 10's of thousands of others
> will evaluate in millions of routers to determine reachability of our

wait, now you added a 3rd item:
  3) rpki data repository/publication-point

> information is relegated to "out of scope" of SIDR?

nope, I think the part I was talking about was JUST #1 above. you put
that cert on your router in some implementation-specific manner. Does
the IETF have to (should it?) state there are some operational security
concerns with this? ie: "It is probably a bad idea to copy/paste an
unencrypted private key on a telnet session across the open Internet to
the router."  (that sort of thing could be placed in the bgpsec-ops doc,
it's not there as near as I can tell today).

-chris