[sidr] Freshness belt and suspenders ....

DougM lists <dougm.tlist@gmail.com> Wed, 28 March 2012 08:54 UTC

Return-Path: <dougm.tlist@gmail.com>
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 0DECE21F8959 for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 01:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 wB4nOSfB1lFO for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 01:54:20 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C29AD21F88C6 for <sidr@ietf.org>; Wed, 28 Mar 2012 01:54:19 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so730105bku.31 for <sidr@ietf.org>; Wed, 28 Mar 2012 01:54:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=a49S4zZ8/U1A3hir/t8c9Gi2Um5OKQn5XsUUbys6UYM=; b=QCOCxwZ262AeNCAbg2c9mbjVjZ/Lmgzd2+uyxLrfiVFUmYqrCek3ff0qeGvr11Q0xx p+PrCRhIqzY8gXG8luIrR4OC5LHM3jobQftJ2SxUlfPrOJZBkqEyhC3L98zqfm+HMkPp ixononAA/yujysrWRH9A/W6W+QhAEeGi047EpyJGphRkpDQcDQgVkhvhAOMV63lun2Sa iOHdQYpakqIMbKdtCaa+RYQN0W4F/ods8wu8T6FrWAUHzTwK37fRiVcC2S4epT3spf06 DARduFxXfVXHCi+ZvLcUsh+oMw6FmlO6vhdHLzLaH7F61vr+PsIp/2e6MzypJ6p1h9qA gOiA==
Received: by 10.205.135.132 with SMTP id ig4mr11765130bkc.20.1332924854234; Wed, 28 Mar 2012 01:54:14 -0700 (PDT)
Received: from [130.129.87.191] (dhcp-57bf.meeting.ietf.org. [130.129.87.191]) by mx.google.com with ESMTPS id r14sm4806003bkv.11.2012.03.28.01.54.12 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 01:54:13 -0700 (PDT)
Message-ID: <4F72D1B3.3010603@gmail.com>
Date: Wed, 28 Mar 2012 04:54:11 -0400
From: DougM lists <dougm.tlist@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: sidr@ietf.org
References: <20120328081939.GA19843@slice>
In-Reply-To: <20120328081939.GA19843@slice>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [sidr] Freshness belt and suspenders ....
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, 28 Mar 2012 08:54:21 -0000

I thought John Scudder's belt and suspenders comment was a good one.   
We have looked at some level of detail at both explicit expire times in 
updates and key roll techniques to manage freshness of BGP updates.   
Neither approach is a silver bullet and both have the potential to swamp 
the system with either updates or updates and RPKI data.

Ideas discussed to date of bounding the potential load imposed by either 
single mechanism are imperfect.   Without bounds, either mechanism could 
be abused at the expense of the entire net.

Sandy has called previously for a discussion of the general requirements 
for "the freshness/replay problem".    Assuming we don't want to leave 
the problem half solved (e.g., deal with withdraw suppression as well as 
explicit replay and peering topology changes), the idea of combining 
mechanisms seems to offer an opportunity.

Combining John and Randy's comments  during the discussion .....

Assume we bound the units of expire time to days (for example, choose 
your acceptable background granularity) past epoc.    Assume we express 
bounds that components MUST support at least two pre-published keys per  
router/AS.

Emergency or topology driven key roll at the router, works at speed of 
BGP convergence.   Day based expire times catch those freshness problems 
that can't be addressed by router key roll.

Some bounds are necessary to prevent / discourage me from pre-publishing 
vast number of router keys signed with very short lived certificates 
..... i.e., I can churn the system just as bad with frequent key rolls 
on routers.

Anyway, combining the two mechanisms would give us a reactive system 
(router key roll) along with a background system that covers the rest of 
the threat space.

I think that was John's point.
dougm