Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt
Brian Dickson <brian.peter.dickson@gmail.com> Tue, 01 November 2011 18:34 UTC
Return-Path: <brian.peter.dickson@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 D75FC21F8E33 for <sidr@ietfa.amsl.com>; Tue, 1 Nov 2011 11:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.547
X-Spam-Level:
X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 nFvdV1CvSKc3 for <sidr@ietfa.amsl.com>; Tue, 1 Nov 2011 11:34:51 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9562621F8C37 for <sidr@ietf.org>; Tue, 1 Nov 2011 11:34:25 -0700 (PDT)
Received: by faas12 with SMTP id s12so8037334faa.31 for <sidr@ietf.org>; Tue, 01 Nov 2011 11:34:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cDi/yZZezEn9QZHvsa3oMs16uSwaKfHlcmYvMd+yu+8=; b=TXMa1+Nv8/1wpWfwsED0SV1JBeQAn+iTGDKSOby3/Ym+o2fsDPutj5qdHACq3RVMf+ GTe21ILl6Rk89ZP22oCKxQ0cQPwT1DbyCEANj0YKCwUIxTByia1b+0vl8ppd990AS7hk SQEqMUbdAj7DEUaJP1aUKG83vCTQK5mMHZE9E=
MIME-Version: 1.0
Received: by 10.223.5.82 with SMTP id 18mr2307688fau.27.1320172445033; Tue, 01 Nov 2011 11:34:05 -0700 (PDT)
Received: by 10.223.54.15 with HTTP; Tue, 1 Nov 2011 11:34:04 -0700 (PDT)
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:34:04 -0400
Message-ID: <CAH1iCipx7JJKSJE6WnnB=zbx-F562By0H9C6xyOQsggEFQbAzA@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Matt Lepinski <mlepinski@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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
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:34:52 -0000
I've read the draft, and find it to be very high quality and very clear. The one comment I have regarding pCount, is in regards to processing received pCount=0 announcements. I believe the concerns regarding "AS-path cheating" to attract traffic, by using pCount=0, could be addressed with some special handling. Basically, when receiving pCount=0 at the top of the stack (most recent addition, by one's peer), checking the next-hop to ensure it satisfies "three-routing" requirements, i.e. that the next hop be something other than the neighbor's IP address, is sufficient. The only other suggestion is related to the number of signature blocks. I agree that support for two is needed at a minimum. I am not entirely sure that restricting it to two is necessary, but haven't thought through the scenarios here. Perhaps "one or more" rather than "one or two"? Has there been any thought to use of a cryptographically signed "Expire Time" (which can be sent and updated as a keep-alive/add-time-to-the-meter mechanism), and then having the blocks refer to the Expire Time by reference (and have the reference internally by pointer, originally matching a cryptographic hash on the first received timer, whose pointed-to value gets updated)? This reduces the "beacon" issue to updating a single value, and limits the playback to the interval during which the original Expire Time exists. Newer updates would refer to the latest cryptographic hash of the last sent Expire Time (update). It becomes a chaining exercise in a state-ful environment... Brian On Tue, Nov 1, 2011 at 12:59 PM, Matt Lepinski <mlepinski@bbn.com> wrote: > I have updated the BGPSEC protocol specification. > > 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. > > 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. > > Finally, there are a number of small editorial changes that I believe will > improve the clarity of the draft. Thanks again to everyone who has reviewed > the document, feedback on how the text could be made more easily > understandable is especially welcome. > > - Matt Lepinski > > > > > On 10/31/2011 3:38 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Secure Inter-Domain Routing >> Working Group of the IETF. >> >> Title : BGPSEC Protocol Specification >> Author(s) : Matthew Lepinski >> Filename : draft-ietf-sidr-bgpsec-protocol-01.txt >> Pages : 28 >> Date : 2011-10-31 >> >> This document describes BGPSEC, an extension to the Border Gateway >> Protocol (BGP) that provides security for the AS-PATH attribute in >> BGP update messages. BGPSEC is implemented via a new optional non- >> transitive BGP path attribute that carries a digital signature >> produced by each autonomous system on the AS-PATH. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >
- [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