[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.)
- [sidr] New Version: draft-ietf-sidr-bgpsec-protoc… Matthew Lepinski
- Re: [sidr] New Version: draft-ietf-sidr-bgpsec-pr… Randy Bush