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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
