[sidr] comments on draft-ietf-sidr-bgpsec-protocol-14 -- editorial

["Sriram, Kotikalapudi" <[e-mail]>]

Matt,

I hope you find these comments helpful.

Comments/Suggestions to help improve clarity/presentation:
-----------------------------------------------------¬--------------------------

Page 3, 3rd para: add [20] next to [19]; both are relevant references.

Page 5, 1st para: s/…for the same AFI combination…/…for the same AFI …/

Page 8, 1st para:  s/(i.e., the number of  AS numbers in the path)/
(i.e., the number of distinct AS numbers in the path)/

Page 14, 1st para: At the end of this para, within the parentheses, I suggest adding: 
See Section 4.4 for an algorithm for reconstruction of AS_PATH attribute.

Page 15: 2nd last para: 
s/…populated with the length (in octets) of the Signature field/
…populated with the length (in octets) of the value in the Signature field/

Page 17, 2nd para from bottom: 
s/ …if the next most recently added Secure_Path segment…/
…if the immediately following Secure_Path segment…/

Note that "next most recently added Secure_Path segment" connotes 
"immediately preceding Secure_Path segment" (i.e. going backward in time). 
It seems to me, that is not what was intended here.

Page 18, 1st para: At the end, add the following: (see Section 5.2).

Page 18, please append the following at the end of the 1st para:
Before attempting to reconstruct an AS_PATH for the purpose of forwarding 
an unsigned (non-BGPsec) update to a peer, a BGPsec speaker MUST
perform the basic integrity checks listed in Section 5.2 to ensure that the received
BGPsec update is properly formed.

Page 19, last para: s/ via the RTR protocol/ via the RPKI-to-Router (RTR) protocol [15]/

Pages 20-21, Section 5.1: The mention of ROA and the second bullet item (top of page 21) 
are not needed here, because ROA is not used in BGPsec validation (origin validation does that).

Page 22, last para:
"If there is no Signature_Block
   corresponding to an algorithm suite that the BGPsec speaker supports,
   then the BGPsec speaker MUST treat the update message in the same
   manner that the BGPsec speaker would treat an (unsigned) update…"

Note that the former (without supported algorithm suite) is not the
same as unsigned, so they cannot be treated in the same manner.
So I think it would be more precise to say it the following way:
"If there is no Signature_Block corresponding to an algorithm suite that 
the BGPsec speaker supports, then the BGPsec speaker MUST 
process the update message as follows: First, convert the Secure_PATH
attribute to AS_PATH attribute, and then treat the update
as if it was received unsigned (non-BGPsec)."

Page 23, in the Figure: s/Rest of Secure_Path/Preceding portion of Secure_Path/

Note that "Rest of Secure Path" implies Secure_Path segments before and after the current one. 
Minor modifications in the text on page 24 also need to be made,
wherever "Rest of Secure_Path" is mentioned. 

Page 25 (1st full para):
"If at least one Signature_Block is marked as 'Valid', then the
   validation algorithm terminates and the BGPsec update message is
   deemed to be 'Valid'.  (That is, if a BGPsec update message contains
   two Signature_Blocks then the update message is deemed 'Valid' if the
   first Signature_Block is marked 'Valid' OR the second Signature_Block
   is marked 'Valid'.)"

I think we cannot say here "…BGPsec update message is deemed to be 'Valid'."
This document only specifies validation for Signature_Block (or Secure_Path).
It is up to the operator to combine the result of RFC6811 (origin validation)
with the results of this document (path validation) to decide about
the overall validity of the BGPsec update message.  
So, instead of "is deemed to be 'Valid' ", should we say "is deemed to be 'Path Valid' "?

Page 27, 1st paragraph (below the bullet): 
"That is, the recipient of a valid BGPsec Update message is assured
   that the Secure_Path portion of the BGPsec_Path attribute corresponds
   to a sequence of autonomous systems who have all agreed in principle
   to forward packets to the given prefix along the indicated path.  (It
   should be noted that BGPsec does not offer any guarantee that the
   data packets would flow along the indicated path; it only guarantees
   that the BGP update conveying the path indeed propagated along the
   indicated path.)"

I find the first sentence problematic. In essence, it contradicts the second sentence.
The first sentence says BGPsec assures something about the data plane.
The second sentence says BGPsec does not guarantee anything about the data plane!
I would reword the first sentence as follows:
"That is, the recipient of a valid BGPsec update message is assured that 
the update propagated via the sequences ASes listed in the Secure_Path 
portion of the BGPsec_Path attribute."

Page 27, 1st paragraph (below the bullet), in the last sentence:
s/ the recipient is assured that this path terminates.../ the recipient is assured,
due to origin validation, that this path terminates…/

Note: I suggest this wording because BGPsec does not provide this 
particular assurance; origin validation does.

Page 30, 2nd para (last para of Section 7.4): 
This appears to be a carryover from v.13 draft since it refers to old Sections 4.1 and 4.2. 
It is also worth noting that the extremely unlikely attack 
being mentioned here is made even more unlikely due to 
more data that needs to be signed over at the second AS (based on this v-14 draft).
     
===========
Typos, Nits:
---------------

Page 12, 3rd para: s/…update message has not been that has not successfully validated/
…update message has not been successfully validated/

Page 15, 1st para: same sentence twice in the same para … 
"the Target AS Number is the AS to whom the BGPsec speaker intends to send the update message"
Similar sentence appeared earlier in the same para at bottom of page 14).

Page 16, 1st para: The following phrase is repeated twice in the same para:
"when a confederation member sends a BGPsec update message to a peer 
that is a member of the same confederation"

Page 16, 1st para: The following phrase is repeated twice in the same sentence (last sentence):
"in a non-BGPsec update message"

Page 25, 2nd para in Section 6.1:
s/a mandatory algorithm suites document will be created/  
a mandatory algorithm suites document exists/ 

References: [9] should have date of November 2015 (it shows Nov. 2014).

Page 17 and p.22:    s/RFC WXYZ/RFC 7606/

Global substitution: s/AS_Path/AS_PATH/g

Global substitution: s/BGPSEC/BGPsec/g

Thank you.
Sriram