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
- [sidr] I-D Action: draft-ietf-sidr-bgpsec-protoco… internet-drafts
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pro… Matt Lepinski
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pro… Danny McPherson
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pro… Brian Dickson
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pro… Randy Bush
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pro… George, Wes
- [sidr] various Randy Bush
- Re: [sidr] various George, Wes
- Re: [sidr] various Randy Bush
- Re: [sidr] various George, Wes
- Re: [sidr] various Randy Bush
- Re: [sidr] various George, Wes
- Re: [sidr] various Danny McPherson
- Re: [sidr] various Randy Bush
- Re: [sidr] various Brian Dickson
- Re: [sidr] various George, Wes
- Re: [sidr] various Randy Bush
- Re: [sidr] various Brian Dickson
- Re: [sidr] various Randy Bush
- Re: [sidr] various Brian Dickson