Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt

"Danny McPherson" <danny@tcb.net> Tue, 01 November 2011 18:22 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 66EB011E80E6 for <sidr@ietfa.amsl.com>; Tue, 1 Nov 2011 11:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vd1K0GmnC8AV for <sidr@ietfa.amsl.com>; Tue, 1 Nov 2011 11:22:56 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id CF50411E80C9 for <sidr@ietf.org>; Tue, 1 Nov 2011 11:22:56 -0700 (PDT)
Received: from webmail.tcb.net (localhost.localdomain [127.0.0.1]) by dog.tcb.net (Postfix) with ESMTP id 016A526800D; Tue, 1 Nov 2011 12:09:31 -0600 (MDT)
Received: from 216.168.239.87 (SquirrelMail authenticated user dpop@tcb.net) by webmail.tcb.net with HTTP; Tue, 1 Nov 2011 14:09:32 -0400 (EDT)
Message-ID: <4548.216.168.239.87.1320170972.squirrel@webmail.tcb.net>
In-Reply-To: <4EB02586.5010101@bbn.com>
References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com>
Date: Tue, 01 Nov 2011 14:09:32 -0400
From: Danny McPherson <danny@tcb.net>
To: Matt Lepinski <mlepinski@bbn.com>
User-Agent: SquirrelMail/1.4.10a-1.fc6
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: sidr@ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: danny@tcb.net
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: Tue, 01 Nov 2011 18:22:58 -0000

> At the SIDR meeting in Quebec, there was significant discussion about
> how BGPSEC could provide security of the AS-PATH attribute while still
> accommodating the needs of route servers that participate in BGP, but do
> not wish to increase the length of the AS-PATH attribute. The -01
> version of the draft contains  a mechanism (a field called pCount) which
> attempts to address this issue by having route servers create BGPSEC
> signatures without increasing the effective length of the AS-PATH
> attribute. I would greatly appreciate comments on this mechanism and
> whether it adequately addresses the issues raised at the last SIDR
> meeting and subsequently discussed on the list.

If we do this we're disclosing routing topology information that is NOT
disclosed today (i.e., an otherwise transparent route server in the BGP
path).  IIRC, not disclosing new information was an explicit requirement?

> There was has also been significant discussion on the SIDR list of the
> "Expire TIme" field in BGPSEC and the associated "Beacon-ing" (that is,
> periodic re-advertisement of a prefix with a new signature and a new
> Expire Time) as a mechanism to address replay attacks (as well as
> attacks where a malicious peer fails to propagate the withdrawal of a
> route). My understanding is that the consensus of  the working group was
> that the current Expire Time mechanism is reasonable as long as
> re-advertisement is only required at the origin AS (and not at
> intermediate ASes). The current -01 version of the draft attempts to
> reflect that consensus.

Can you provide a pointer to where this was discussed AND consensus was
reached in the WG, I don't recall seeing any consensus and I'm still very
concerned about adding periodic updates and considerable churn to an
otherwise stateful system in order to minimize exposure windows to
multiple hours (or more).

Furthermore, given the systemic and architectural implications of such a
mechanism, I would like to see an explicit consensus call on this item
from the chairs.  I also think this is something that should be consulted
with the IDR WG, as periodic updates ("beacons") are a considerable step
away from the stateful BGP we know today -- and when coupled with single
NLRI-only UPDATES an order of magnitude or larger that require
cryptographic validation of many component elements, it makes me uneasy.

-danny