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
>