Re: [sidr] beacons and bgpsec

George Michaelson <ggm@pobox.com> Wed, 10 August 2011 01:14 UTC

Return-Path: <geeohgeegeeoh@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 2FADF21F8B05 for <sidr@ietfa.amsl.com>; Tue, 9 Aug 2011 18:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 imLY9Y0OUgB0 for <sidr@ietfa.amsl.com>; Tue, 9 Aug 2011 18:14:44 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4039921F89C2 for <sidr@ietf.org>; Tue, 9 Aug 2011 18:14:44 -0700 (PDT)
Received: by yxp4 with SMTP id 4so441255yxp.31 for <sidr@ietf.org>; Tue, 09 Aug 2011 18:15:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Vxnd/AdpqvZeTdyBiXL38QSq7WxvRaTLSqMj9Ov7QgA=; b=hoo4FZy4/k1gcBUKVjvslbkU7z8LzbpI3hwAGybavuOGkn74EZzyZaiRKGplm4HZP5 EqR/In4ZhE0Y/SQLGGT79QPv1eU/0UKRsoJwkG9QoYLAFzuJdjmIfBAbq1bcIxfxME6G hoDcZNYboYSGZidjxuKZd+2ugSlrWXqrnTpRc=
Received: by 10.100.245.35 with SMTP id s35mr6682210anh.84.1312938914252; Tue, 09 Aug 2011 18:15:14 -0700 (PDT)
Received: from dynamic201.apnic.net (dynamic201.apnic.net [203.119.42.201]) by mx.google.com with ESMTPS id o11sm404461anh.23.2011.08.09.18.15.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 18:15:13 -0700 (PDT)
Sender: George Michaelson <geeohgeegeeoh@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="us-ascii"
From: George Michaelson <ggm@pobox.com>
In-Reply-To: <A37CADA4-F16D-4C01-8D9C-D01001C4EFE4@tcb.net>
Date: Wed, 10 Aug 2011 11:15:09 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org>
References: <A37CADA4-F16D-4C01-8D9C-D01001C4EFE4@tcb.net>
To: Danny McPherson <danny@tcb.net>
X-Mailer: Apple Mail (2.1244.3)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] beacons and bgpsec
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, 10 Aug 2011 01:14:45 -0000

On 10/08/2011, at 11:06 AM, Danny McPherson wrote:

> 
> The discussion of "Beacons" at the last meeting reminds of of EIGRP's 'triggered updates" v. RIP's "periodic updates" (i.e., cousin of beacons)...
> 
> I think Randy successfully convinced me during his talk at the Quebec City WG session that "beacons" at a frequency of 24 hours (or anything in the "hours" range) are pretty much useless and add considerable churn and complexity with little return from a practical attack surface perspective.  
> 
> With the lifetime of the average phishing site being only ~55 hours (for many reasons, I know), and an inclination to believe that infrastructure threats are likely to be even more temporal, and I'm inclined to recommend that beacons be removed altogether in their current incarnation of bgpsec, as there are plenty of other scale issues to focus on. 
> 
> Further study on alternatives, downstream purging issues, and clock skew for network elements might be useful in this context.  I saw something on the DANE list from PHB about vast skew across end systems, wondering if anyone has measured this?
> 
> Thoughts?
> 

Forgive a peanut gallery observation, but are we defining things as useless which we cannot understand in RPKI, because to admit that we don't understand them in RPKI means making RPKI more complex?

-G