[sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
"Suresh Krishnan" <suresh.krishnan@ericsson.com> Wed, 04 January 2017 04:02 UTC
Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D39127A91; Tue, 3 Jan 2017 20:02:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148350252902.27921.8666847752091341028.idtracker@ietfa.amsl.com>
Date: Tue, 03 Jan 2017 20:02:09 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/f4AMOXqlCHJ1wnvvTrdefP6ISBE>
Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org
Subject: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 04 Jan 2017 04:02:09 -0000
Suresh Krishnan has entered the following ballot position for draft-ietf-sidr-bgpsec-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.1 The IANA registry at http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml may be a better reference for AFIs than RFC4760. * Section 4.2 Is there a specific reason that the signature construction algorithm orders the fields in the way it does? It does look pretty complicated to parse out and arrange the fields this way from the BGPsec packet that was received. Something like the following seems much simpler to calculate +------------------------------------+ | Target AS Number | +------------------------------------+ ---\ | Signature Segment : N-1 | \ +------------------------------------+ \ ... | +------------------------------------+ | | Signature Segment : 2 | | +------------------------------------+ | | Signature Segment : 1 | \ +------------------------------------+ > Data from | Secure_Path Segment : N | / N Segments +------------------------------------+ | ... | +------------------------------------+ | | Secure_Path Segment : 2 | | +------------------------------------+ / | Secure_Path Segment : 1 | / +------------------------------------+---/ | Algorithm Suite Identifier | +------------------------------------+ | AFI | +------------------------------------+ | SAFI | +------------------------------------+ | Prefix | +------------------------------------+ as the segment fields and signature fields are naturally grouped together in the packet. Is there a difference in cryptographic strength between these two constructions?
- [sidr] Suresh Krishnan's No Objection on draft-ie… Suresh Krishnan