Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)

Randy Bush <randy@psg.com> Wed, 13 February 2019 03:41 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C54130F8A; Tue, 12 Feb 2019 19:41:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 Wui1KUGNwnwE; Tue, 12 Feb 2019 19:41:08 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 831CC130F80; Tue, 12 Feb 2019 19:41:08 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1gtlPu-0000jr-Dz; Wed, 13 Feb 2019 03:40:58 +0000
Date: Tue, 12 Feb 2019 19:40:57 -0800
Message-ID: <m2tvh8jqye.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Benjamin Kaduk <kaduk@MIT.EDU>, draft-ietf-sidrops-rtr-keying@ietf.org, The IESG <iesg@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, SIDROps Chairs <sidrops-chairs@ietf.org>, SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com>
References: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com> <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/HZj9Hj9KJxY1Wbk8PCYer_POSWE>
Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2019 03:41:10 -0000

> Would something like the following work:
> 
>    The operator-driven model is motivated by ensuring the network
>    operates.  In some deployments, the same private key needs to be
>    installed in the soon-to-be online router that was used by the the
>    soon-to-be offline router (i.e., operators need to support
>    hot-swappable routers.

would add something about possuble O(day) RPKI propagation, thanks geoff

>>   When a router is so configured, the communication with the CA SHOULD
>>   be automatically re-established by the router at future times to
>>   renew or rekey the certificate automatically when necessary (See
>>   Section 9). This further reduces the tasks required of the operator.
>> 
>> Mentioning renewing certificates is natural, as they have a stated end time
>> to prepare for.  Re-keying certificates is something of a different matter,
>> and it would be nice to provide (a link to) some guidance on what
>> timescales at which to rekey, if we're mentioning rekeying here.
>> (draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I
>> did not see much concrete on this point.)
> 
> We’d end up in a circular reference point then since they point to our
> document.  The thing here is that the lifetimes of the keys are
> entirely dictated by the PKI CPs and there’s more than one place to
> point.  Not sure I have good fix for this one.
> 
> Randy/Keyur?

i do not see router private keys changing frequently.  a paranoid op
might re-key yearly.  others never.

>>   To allow operators to quickly replace routers without requiring
>>   update and distribution of the corresponding public keys in the RPKI,
>>   routers SHOULD allow the private BGPsec key to be inserted via a
>> 
>> Making this a SHOULD is perhaps an overstatement, since AFAICT this
>> functionality is not useful for the stated purpose unless the operator has
>> access to private keys directly (whether by virtue of the operator having
>> generated the keys or an extraction interface on the current routers).
>> This is an inherent tradeoff, as stated, between the delay in
>> update/distribution of public keys in the RPKI vs. reducing the risk of
>> unauthorized key access.  I'm not making this a Discuss point because it's
>> not exactly my tradeoff to make, but I do want to be sure that this is
>> actually the tradeoff that SIDROPS wants to present to the community.
> 
> It’s definitely been in the draft for a while now.  I guess folks can
> speak up if they think it’s wrong.
> 
> Randy/Keyur?

we are going over the same issue from another angle.  maybe in 2050,
when bgpsec is deployed, the rpki will be sufficiently responsive to
change that a vendor could sell a router that only did the key export
thing.  not today.

to repeat my message to ben from 22 jan

it's 2am.  the bleeping device melted.  a new key generated by a
replacement device will take a good while to get into the rpki and then
many more hours to get into everybody's bgpsec validation key caches
around the planet [ask geoff why he insisted he did not have to publish
more frequently than once a day].  and by 3am, people with shiny shoes
will be giving the op snake eyes that customers in tiblisi can't give
them money online right now.  when the op tells them it will be tomorrow
afternoon, it is usually referred to as a resume generating event.

randy