[sidr] New Version: draft-ietf-sidr-bgpsec-protocol-11

Matthew Lepinski <mlepinski.ietf@gmail.com> Tue, 20 January 2015 00:50 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEEA1B2D56 for <sidr@ietfa.amsl.com>; Mon, 19 Jan 2015 16:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A9URFBsUBPE for <sidr@ietfa.amsl.com>; Mon, 19 Jan 2015 16:50:04 -0800 (PST)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953661B2C5E for <sidr@ietf.org>; Mon, 19 Jan 2015 16:50:04 -0800 (PST)
Received: by mail-oi0-f43.google.com with SMTP id z81so1472865oif.2 for <sidr@ietf.org>; Mon, 19 Jan 2015 16:50:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=r88llEKUAR97THQkKuUc92EGccm3wMWxyB6Wpr0gdwc=; b=GPPCCL7QZi4IiFAq5wLA4CEm4KW/hrhCWCFZc1Rmzd25kdgzO1AcIU0svISblkVm1M M6li0YOC4sldsE/ErD8GPmohtIZDJTkA51hyCLnuekLFpYSj6crrzZjX/TfgT+/sLAen d4ZhfKxfYKALe89lb5N/2nikCIgWDThNSpnAEs2k00YI3H+WbdOqVJX0VGMognhPmQeX 8AQC46GmVLBg30uqeczKzNdET7W8jN2iAaB3Yp0MBhPOmWluDCYjM8h93cjt2d3OUlKO 28em1bHpQgp4S/06zAO/j9DHD+jdT6pNUok1yIcKJFvjU9KAE+Gz8ilokaMNak4xJqcb evvQ==
MIME-Version: 1.0
X-Received: by 10.202.19.132 with SMTP id 4mr18877960oit.10.1421715003568; Mon, 19 Jan 2015 16:50:03 -0800 (PST)
Received: by 10.202.135.17 with HTTP; Mon, 19 Jan 2015 16:50:03 -0800 (PST)
Date: Mon, 19 Jan 2015 19:50:03 -0500
Message-ID: <CANTg3aCZuiuMPNZ80-yfwL43Uwu57fRGFTKUuXp2qop-crqqEg@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Content-Type: multipart/alternative; boundary="001a113dfb78c276a5050d0ad126"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/zy44zDS_Uje3WvOjaCR04TNQSac>
Subject: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-11
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Jan 2015 00:50:07 -0000

I have just submitted a new version of the BGPsec protocol document. This
version includes text changes to improve the security considerations
section of the document as well as review comments based on the previous
version of the document. (In particular, many thanks to Sriram -- for his
very  thorough review -- and to everyone who made helpful comments on the
list.) Also, to make this document consistent with other documents in the
document suite, this document now specifies a BGPsec_Path attribute instead
of a BGPSEC_Path attribute.

====================
One minor issue that arose in making these revisions:

Consider the case where you are creating a new update message somewhere
within your AS (to originate a route to one of your own prefixes) and you
are sending this new update message via iBGP to an internal peer. The
document currently says that you omit the Secure_Path attribute (that is,
the BGPsec_Path attribute is added by your edge router ... since the
signature depends on the eBGP peer to whom an update is being sent).

An alternative would be to include an 'empty' BGPsec_Path attribute ...
that is, one with zero Secure_Path segments and zero Signature segments.

If you think sending an empty BGPsec_Path is better than omitting the
BGPsec_Path, please speak up now. (Both approaches seem perfectly fine to
me.)