Subject: [sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 03 Jan 2017 20:02:09 -0800

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?