[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?