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

Danny McPherson <danny@tcb.net> Wed, 11 April 2012 17:45 UTC

Return-Path: <danny@tcb.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 6030C21F855B for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 wT2l1QRwPGwc for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:45:15 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 149B821F8564 for <sidr@ietf.org>; Wed, 11 Apr 2012 10:45:14 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 87A86268063; Wed, 11 Apr 2012 11:45:13 -0600 (MDT)
Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 11 Apr 2012 11:45:13 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=216.168.230.7; client-port=50286; syn-fingerprint=65535:53:1:64:M1460,N,W1,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DDD369C8-4DC1-4445-830B-52EB8E88A7AD"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com>
Date: Wed, 11 Apr 2012 13:45:09 -0400
Message-Id: <C533B89C-F817-4111-A532-0165EC5D6786@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>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: sidr wg <sidr@ietf.org>, sidr-chairs@tools.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 17:45:16 -0000

On Apr 11, 2012, at 1:35 PM, Christopher Morrow wrote:
> 
> 
>> From there, we can discuss the issue of, for example, HOW TO onboard and purge signing and validating certificates to routers from the RPKI -- [I suspect the intention was to use rpki-rtr protocol for this, but it doesn't currently support it, nor are the security implications clear].
>> 
> 
> The rtr cert/ee-cert part was never planned/designed to be done via rpki-rtr.
> Ideally at provisioning time your ee-cert is dropped onto the box,
> similar to base-config today. Potentially your fav vendor has a
> methodology in their plan for this. I can't imagine it's too tough,
> nor that it's exact specification needs to be in an IETF doc (since it
> seems implementation specific). Could be wrong though.

It has huge implications on the scale and operations, particularly when considering how rollovers and other such changes are effectuated.  Also, decoupling these entirely from validating certificates means I've got two mechanisms now for on-boarding [just] these things.  I'd prefer not to leave this to "magic happens" given that it's foundational to pretty much everything else that's being built.

> sure, some modelling seems like a good thing here, I think this was
> asked for at the mic in PAR as well, no? (in response to some
> discussions with Sriram?)

Yep!

> we can chat about that on-list or in the meeting... I suppose there's
> a slew of milestones which are 'complete', there aren't really any
> changes (that I planned) from an 'adding things' perspective. The
> ops-documentation (see wiki) to me is probably NOT an ietf document,
> again happy to talk at the meeting about that though.


I'd be interested in lining out the longer-term deliverables for the group on the list..

-danny