Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-protocol-18

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Alvaro,

Thank you very much for this thorough and detailed set of comments.

They greatly help improve the clarity, accuracy, and presentation in the document.

I have worked with each of the comments and incorporated changes accordingly

in the document. Please see version-19 that was just submitted.

Many thanks to Sean Turner for his help with the updated IANA considerations section.

My responses to your individual comments are shown below and are marked with [Sriram].

Let me know if the pdf opens OK for you.

Also, please let me know if I missed anything.

Regards,

Sriram

P.S. I tried to send this message with a pdf attachment earlier to the SIDR list.

But looks like that post was not accepted by the IETF email exploder due to the attachment, may be?

So I have copied and pasted here the text from the pdf.

There may be line-wrap issue -- let us see.

-----------

Dear authors:

Hi!  First of all, thank you for taking on the duties of editing this document.


I have several comments (see below).  For the most part, I think they should be easy to solve as many are related to clarifications.  Most of the comments I classified as Major are due to the use of Normative language.


The biggest concern I have with this document is the lack of an Operations and Management Considerations Section – please take a look at RFC5706 (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions).  Some of the information suggested there is present in draft-ietf-sidr-bgpsec-ops, and (ironically) in the “Design and Deployment Considerations” section of draft-ietf-sidr-bgpsec-overview.  However, important items such as migration or management are missing.  I would like to see a well thought out Operations and Management Section in this document before moving it forward.  Note that I’m not suggesting that a YANG model (for example) is required to move forward, but I would like to see considerations about migration, and the impact on network operations, to mention two items, all in one place in the document.  I would like the authors/Chairs/Shepherd/WG to consider even merging in draft-ietf-sidr-bgpsec-ops as the base for this new section (or at least reference it prominently).

[Sriram] Following the clarifications and additional guidance you provided in Seoul (when you, Chris, and I met), I have added a new Section 7 (Operations and Management Considerations). The topics you mention above are all covered in the new Section 7. Additional responses noted here below under your specific comments.

Thanks!

Alvaro.

Major:

M1. Registry Definitions

M1.1. Section 2.1. (The BGPsec Capability) includes a Version field and some Reserved bits, but there are no IANA registries defined for how to manage these spaces.  Please define the registries and the corresponding registration procedures.

[Sriram] Done. Please see the updated IANA Considerations section.

M1.2. Section 3.1. (Secure_Path) defines the Flags field and assigns the first bit (BTW, is that the MSB or the LSB, please clarify), but doesn't set up the registry or registration procedures.

[Sriram] It is the MSB (left most bit) and that is now clarified in Section 3.1. Set up of the registry for the Flags field is now included in the updated IANA Considerations section.



M2. Error Handling — Several sections don't have proper error handling procedures specified. (This is a management issue that I think is underspecified.)

[Sriram] Now there is management and operations section (Section 7) added where error handling and other ops/mgmt. issues are discussed.

M2.1. Section 2.2. (Negotiating BGPsec Support) doesn't fully specify the error handling behavior of the Capability, and it fails open.

[Sriram] See my responses below for M2.1.1.

The new management and operations section (Section 7) covers this case.

M2.1.1. What should the action be if the Version is not 0?

[Sriram]: From Section 2.2:

“BGP

   update messages without the BGPsec_Path attribute MAY be sent within

   a session regardless of whether or not the use of BGPsec is

   successfully negotiated.”

[Sriram] Based on the above, there is a possibility that BGPsec is not successfully negotiated but BGP is session is established – I think that is what you are calling fail open. If the intersection of BGPsec capability advertisements from both sides does not include Version 0, then BGPsec Version 0 has not been successfully negotiated. But a BGP session is still negotiated and BGP (unsigned) messages are exchanged. I have now included this wording in the new ops/mgmt. Section 7.

M2.1.2. "…a BGP speaker MUST NOT advertise the capability of BGPsec support for a particular AFI unless it has also advertised the multiprotocol extension capability for the same AFI [RFC4760]."  What should happen if it does advertise an AFI that is not covered by the multiprotocol extension capability?   Or if the multi-protocol capability is not advertised at all?  To clarify: if the multi-protocol capability is not advertised then support for BGPsec can’t be advertised either – does that mean that a BGP speaker configured to use BGPsec must not use it if not negotiated?  I know the answer is “yes”, but I’m trying to get to the point of provisioning and expectations – why configure BGPsec if no one is expected to support it?

[Sriram]: See response to 2.1.1 above. Also, during early phase of deployment, small groups of (consisting of 2 or more) ASes are likely to coordinate and deploy BGPsec over contiguous regions (ASes). These regions will grow over time and conjoin.  Also based on clarifications you provided in Seoul, I have also included error handling considerations for the case when BGPsec resets and some necessary condition (like 4-byte ASN or MP-NLRI capability) got dropped in the meantime.

M2.1.3. Missing the four-byte AS capability results in BGPsec not working ("BGPsec has not been successfully negotiated"), but the ability of exchanging routes is still there, leaving the system in a fail open state and potentially breaking the chain of ASNs.  Personally, it doesn't seem like a good result — please at least include some text about this in the Security Considerations section.

[Sriram] Even though BGPsec is not successfully negotiated, the ability of exchanging routes is still there – BGP messages are exchanged though not BGPsec; it so the chain of ASNs in not really broken (they are not contiguous for BGPsec but still contiguous for BGP). This observation is included in the new Section 7 (ops/mgmt. section).

M2.2. The definition of the BGPsec_Path Attribute (and its details) don't have clear error handling procedures defined (RFC7606).  Section 4.3. (Processing Instructions for Confederation Members) does say this: "(As discussed in Section 5.2, any error in the BGPsec_Path attribute MUST be handled using the "treat-as-withdraw", approach as defined in RFC 7606 [RFC7606].)" (including the parentheses).  However, 5,2 only says: "BGPsec speakers MUST handle these errors using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606]."   Note: "these errors" is not the same as "any error".  Please discuss error handling in a more prominent place. (Hint: it may fit in a fault management discussion in the Operations and Management Section.)

[Sriram]  s /As discussed in Section 5.2, any error in the BGPsec_Path attribute MUST be handled using the "treat-as-withdraw", approach as defined in RFC 7606 [RFC7606]./ As discussed in Section 5.2, any syntactical or protocol violation errors in the BGPsec_Path attribute MUST be handled using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606]./

[Sriram]  Section 4.3 has been updated accordingly.

M2.2.1. There are multiple places in the BGPsec_Path Attribute that could end up in an error, everything from setting bits in the Flags field to wrong Length fields.  Should all errors result in the same behavior?

[Sriram] Any errors that are syntactical errors or detected to be protocol violation errors in the BGPsec_Path attribute should result in the same behavior (see above comment). I think the updated Section 5.2 enumerates them reasonably well now. But bit errors that may result in change in the value of an ASN or a signature would not fall in that category.

M3. Section 4.1. (General Guidance): "When propagating a received route advertisement to an internal peer, the BGPsec speaker typically populates the BGPsec_Path attribute by copying the BGPsec_Path attribute from the received update message.  That is, the BGPsec_Path attribute is copied verbatim…. Note that when a BGPsec speaker chooses to forward a BGPsec update message to an iBGP peer, the BGPsec attribute SHOULD NOT be removed, unless the peer doesn't support BGPsec."  The first part of the guidance says that a new BGPsec_Path attribute is created by copying the received attribute (which is then presumably removed), but the second part says that the received attribute SHOULD NOT be removed.  Please clarify so that there is consistency -- I understand that the result is the same, but the description is not and we should try to avoid confusion.  Parts of Section 4.2. (Constructing the BGPsec_Path Attribute) also talk about actions like "…and there is an existing BGPsec_Path attribute, then the BGPsec speaker prepends its new Secure_Path Segment (places in first position) onto the existing Secure_Path", which hint at propagating a received BGPsec_Path attribute (and not creating a new one).

[Sriram] Yes, agree. We’ll remove redundant and confusing statements and simply state the stuff in the first set of quotes as follows (here we avoid using the word copying which causes some confusion):

[Sriram] When a BGPsec speaker chooses to forward a BGPsec update message to an iBGP peer, the BGPsec_Path attribute SHOULD NOT be removed, unless the peer doesn't support BGPsec. In the case when an iBGP peer doesn't support BGPsec, then the BGPsec update is reconstructed to a BGP update with AS_PATH and then forwarded (see Section 4.4). In particular, when forwarding to a BGPsec capable iBGP peer, the BGPsec_Path attribute SHOULD NOT be removed even in the case where the BGPsec update message has not been successfully validated.

M4. Section 4.2. (Constructing the BGPsec_Path Attribute) says that "The AS number in this Secure_Path segment MUST match the AS number in the AS number resource extension field of the Resource PKI router certificate(s) that will be used to verify the digital signature(s) constructed by this BGPsec speaker [I-D.ietf-sidr-bgpsec-pki-profiles]."  However, there is no extension field or certificate in I-D.ietf-sidr-bgpsec-pki-profiles with that name.  Please be precise with the names.

[Sriram] Modified as follows: The AS number in this Secure_Path segment MUST match the AS number in the Subject field of the Resource PKI router certificate that will be used to verify the digital signature constructed by this BGPsec speaker (see Section 3.1.1.1 in [I-D.ietf-sidr-bgpsec-pki-profiles] and RFC 6487 [RFC6487]).

M5. In 4.2: “BGPsec speakers SHOULD drop incoming update messages with pCount set to zero in cases where the BGPsec speaker does not expect its peer to set pCount to zero.”  This text seems to assume some kind of configuration/provisioning.  Note that Section 5.2. (Validation Algorithm) also has similar text about receiving an UPDATE “from a peer that is not expected to set pCount equal to zero”.

[Sriram] A peer that is an Internet Exchange Point (IXP) (i.e. Route Server) with a transparent AS is expected to set pCount = 0 in its Secure_Path segment while forwarding an update to a peer (see Section 4.2).  Clearly, such an IXP SHOULD configure itself to set its own pCount = 0. As stated in Section 4.2, “BGPsec speakers SHOULD drop incoming update messages with pCount set to zero in cases where the BGPsec speaker does not expect its peer to set pCount to zero.”  This means that a BGPsec speaker SHOULD be configured so that it permits pCount =0 from an IXP peer and never permits pCount = 0 from a peer that is not an IXP.

Added the above paragraph in the new Section 7.

M6. In 4.2: “If the received BGPsec update message contains two Signature_Blocks and the BGPsec speaker supports both of the corresponding algorithm suites, then the new update message generated by the BGPsec speaker SHOULD include both of the Signature_Blocks.”  Why is this “SHOULD” not a “MUST”?   When/why would a speaker remove one or the 2?  If one is removed, should there be a requirement that the one that was used to successfully validate the update be kept?  Note that Section 7.2 later talks about the problems of removing signatures…

[Sriram]  See below.

M6.1. Note that later in this section the text says that “a 'Valid' BGPsec update message may contain a Signature_Block which is not deemed 'Valid' (e.g., contains signatures that BGPsec does not successfully verify).  Nonetheless, such Signature_Blocks MUST NOT be removed.”   Taking this “MUST NOT” along with the “SHOULD” above, the door is open to remove the Signature_Block used to verify the validity and just forward the one not used (which may itself not be valid).

[Sriram] Your observations are right. Therefore, we made the following change (SHOULD --> MUST): If the received BGPsec update message contains two Signature_Blocks and the BGPsec speaker supports both of the corresponding algorithm suites, then the new update message generated by the BGPsec speaker MUST include both of the Signature_Blocks.

M6.2. Section 5.2. (Validation Algorithm) opens this door even more when saying that “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'.”  The text here doesn’t require that both Signature_Blocks be verified, but implies that as long as the first one is valid then the second one doesn’t really need to be verified.  Is that the intent?

[Sriram]  Yes. There is no problem with early termination since both algorithms are in use in parallel and either one can be used for verification. In fact, it helps with route processor performance to terminate early on a ‘Valid’ outcome after successfully verifying one of the Signature_Blocks.

[Sriram]  We have added a para in the new Section 7 on performance enhancement during BGPsec update validation.

M7. Section 5. (Processing a Received BGPsec Update) talks about “duplicate update messages” (one where “it differs from the first update message only in the Signature fields (within the BGPsec_Path attribute)”).

[Sriram]  ECDSA P256 algorithm produces a different set of signature bits when it signs the same data again at a later time.

M7.1. “With regards to the processing of duplicate update messages, if the first update message is valid, then an implementation SHOULD NOT run the validation procedure on the second, duplicate update message (even if the bits of the signature field are different).”  Even though a discussion about non-deterministic signature algorithms precedes this text, the validation is still not run.  How can the validity of the Path be guaranteed in this case?  Should this be the action for all algorithms or only ones known to be non-deterministic?

[Sriram] Definition of duplicate update for BGPsec: A BGPsec update is a duplicate if it is identical to another update in the Adj-RIB-in, including SKIs and Algorithm ID, but not including the signatures. If the first update message (having the *same SKIs* as the duplicate) is *Valid*, then the duplicate’s validity state need not be computed.  If validity of the duplicate were computed and found 'Valid', then it gives the router no new information. Alternatively, if it were found 'Not Valid', then it only implies that some bit errors occurred in the signatures. Therefore, the BGPsec speaker should keep the 'Valid' original update and ignore the duplicate. However, if the original update were 'Not Valid', then performing validation of the duplicate is relevant and SHOULD be done.

[Sriram] Added a paragraph in the new Section 7 (Operations and Management Considerations) to include the above observations.

[Sriram] Note that the above applies to both non-deterministic and deterministic signature algorithms.

M7.2. rfc4271 (in Section 9. (UPDATE Message Handling) talks about the implicit withdraw of a route “if the NLRI of the new route is identical to the one the router currently has stored…”.  The same NLRI case seems to be a particular condition of the “duplicate update” described here.  It might be a good idea to mention that a “duplicate update” results in the implicit withdraw of the original update.  What happens if a third duplicate route is received (the first one was valid, the second one was not validated), should it be validated?

[Sriram] In RFC 4271, when there is a duplicate update, the NRLI and path and all other attributes are identical. There is no implicit withdraw. The router keeps what it already has. In the case of BGPsec, a router keeps the original if it was valid, and ignores the duplicate. It checks the validity of the duplicate only if the original were invalid.

M8. Section 5.1. (Overview of BGPsec Validation) says that "BGPsec specifies no changes to the BGP decision process."  However, Section 5. (Processing a Received BGPsec Update) also says that "a BGPsec speaker MUST utilize the AS path information in the BGPsec_Path attribute in all cases where it would otherwise use the AS path information in the AS_PATH attribute."  I'm assuming that the Decision Process is included in "all cases".  Even though 5.1 refers to the use the validation state in the decision process, please make sure that it is clear that the decision process is modified by the use of the different attribute.

[Sriram] I agree that making use of validation state in BGPsec implies a change in the decision process.  So we will remove the sentence that says "BGPsec specifies no changes to the BGP decision process."

M8.1. Please specifically include a section (or text somewhere) about how the information in the BGPsec_Path attribute is used in the Decision Process.  For example, how should the "number of AS numbers" in the path be calculated for 9.1.2.2. (Breaking Ties (Phase 2)) in rfc4271?  The text talks about the "effective length" being the sum of the pCount values, but the "effective length" (at least with that name) is not what is used in rfc4172 — please be clear and consistent.

[Sriram] Done the following: s/ effective length of the AS path/ length of the AS path/

[Sriram] Paragraph in Section 3.1 updated as follows:

[Sriram] The pCount field contains the number of repetitions of the associated autonomous system number that the signature covers.  This field enables a BGPsec speaker to mimic the semantics of prepending multiple copies of their AS to the AS_PATH without requiring the speaker to generate multiple signatures. Note that Section 9.1.2.2 ("Breaking Ties") in [RFC4271] mentions "number of AS numbers" in the AS_PATH attribute that is used in the route selection process. This metric (number of AS numbers) is the same as the AS path length obtained in BGPsec by summing the pCount values in the BGPsec_Path attribute.

M8.2. [minor] Section 3. (The BGPsec_Path Attribute) reads: "The information in Secure_Path is used by BGPsec speakers in the same way that information from the AS_PATH is used by non-BGPsec speakers."  This is pretty much the same information that is in Section 5, but with more specificity.  It would help if the more specific case was the one normatively called out.

[Sriram] Made the change -- more specific language (Secure_Path as opposed to BGPsec_Path attribute) is now used in Section 5 also.

M9. Section 5.2. (Validation Algorithm).  RFC4271 also specifies a series of validity checks when an UPDATE is received (Section 6.3) – should that check be run before or after the algorithm specified here?  The algorithm focuses on verifying the validity of the BGPsec_Path attribute (and not the whole UPDATE), so I’m assuming it should be executed instead of checking the AS_PATH.  Please include some text about the interaction/changes.

[Sriram] Section 5.2 has been updated to reflect the above comment.

M9.1.  Section 5.2. (Validation Algorithm): “…then the BGPsec speaker MUST treat the update message in the same manner that the BGPsec speaker would treat an (unsigned) update message that arrived without a BGPsec_Path attribute.”   What exactly does this mean?  If the BGPsec_Path attribute is not received, then the AS_PATH should be – does the text imply that the AS_PATH should be reconstructed?  I guess it should be if the update is to be propagated – but the question is while the update is being processed, which AS path information is used, the one in a reconstructed AS_PATH or the one in the BGPsec_Path while assuming that all the signatures are correct?

[Sriram] Changed the wording. The corrected wording in Section 5.2 is as follows:

[Sriram] Next, the BGPsec speaker examines the Signature_Blocks in the BGPsec_Path attribute.  A Signature_Block corresponding to an algorithm suite that the BGPsec speaker does not support is not considered in validation.  If there is no Signature_Block corresponding to an algorithm suite that the BGPsec speaker supports, then the BGPsec speaker MUST strip the Signature_Block(s), reconstruct the AS_PATH (see Section 4.4), from the Secure_Path, and treat the update as if it was received as an unsigned BGP update.

M10.  In Section 7.2. (On the Removal of BGPsec Signatures): “…the protocol specifies that a BGPsec speaker choosing to propagate the route advertisement in such an update message SHOULD add its signature to each of the Signature_Blocks.”   I believe the reference is Section 4.2 (please add it).  However, that Section doesn’t use normative language (“For each Signature_Block corresponding to an algorithm suite that the BGPsec speaker does support, the BGPsec speaker adds a new Signature Segment to the Signature_Block.”)   In any case, the “SHOULD” in 7.2 is out of place because it is referencing a fact (pointing at the other section) and not being used normatively – if you want the “SHOULD” to be normative, then it should be back in 4.2.

[Sriram] Yes, agree. Fixed the wording per your suggestion in both places (Sections 4.2 and 7.2). Added reference to Section 4.2 in Section 7.2.

M11. The Figures (which are not numbered) in 4.2. (Constructing the BGPsec_Path Attribute) and 5.2. (Validation Algorithm) present the sequence of octets to be hashed.  I’m guessing that the order of the Signature and Secure_Path Segments may be important, is it?  The order in the Figures is not clear to me, if the order is important, please be clear about it; if not, please also say so.

[Sriram] Yes, the order of the Signature and Secure_Path Segments is important. I have put in additional wording for clarifying/rationale and emphasized that the order is important – in both sections.

[Sriram] Figures are numbered now in the document.

M12. The mandatory addition of Secure_Path and Signature segments in a Confederation results in the inconsistent authorization chain mentioned in Section 4.3. (Processing Instructions for Confederation Members): “For a signature produced by a peer BGPsec speaker outside of a confederation, the Target AS will always be the AS Confederation Identifier (the public AS number of the confederation) as opposed to the Member-AS Number.”  It seems to me that this discontinuity in the ASN list breaks the “cryptographic assurance that…Every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route to the subsequent AS in the path” because there is no way to verify that the Member-AS in the first Secure_Path segment is in fact the one peering with the external neighbor.  I realize that the risk may be minimized by an “internal trust” factor, but I would like to see a discussion about this issue in the Security Considerations.

[Sriram] See the new second paragraph in Section 7.4. The security consideration that you mention here about with the way confederations are handled is described and discussed there.

M13. What about replay attacks?  There is no mention of the risk or potential mitigation anywhere.  Please include in the Security Considerations section.

[Sriram]: Added a new paragraph and reference to ietf-sidr-bgpsec-rollover in Section 8.4.

Minor:

m1. The use of SKI, Subject Key Identifier without a qualifier (field, extension) is confusing at times.   Please expand SKI on first use.  An example: (from 3.2) “The Subject Key Identifier contains the value in the Subject Key Identifier extension of the RPKI…”  The first mention should include “field”, like similar text in 4.2.

[Sriram]: Done.

m2. Section 4. (BGPsec Update Messages) says: "A BGPsec speaker that is not a member of such a confederation MUST set the Flags field of the Secure_Path Segment to zero in all BGPsec update messages it sends."  While only one flag is defined, the correct statement is "…set the Confed_Segment flag…".

[Sriram]: Done.

m3. Section 4.1. (General Guidance): s/"A BGPsec update message MUST advertise a route to only a single NLRI."/"A BGPsec update message MUST advertise a route to only a single prefix."   This section contains other places where the NLRI term is not used correctly.  In short, the NLRI in a BGP Update contains one or more prefixes — so the text should talk about a single prefix, not a single NLRI.

[Sriram]  Replaced “NLRI” with “prefix” in all places in the document where appropriate.

m4. In between the text above, the following is written: "However, in the case that the BGPsec speaker is performing an AS Migration, the BGPsec speaker may add an additional signature on ingress before copying the BGPsec_Path attribute (see [I-D.ietf-sidr-as-migration] for more details)."  Because I-D.ietf-sidr-as-migration is marked as Updating this document, I suggest you remove this text (and the one in 4.2) -- note that the statements made in this document are not normative anyway and I-D.ietf-sidr-as-migration can stand on its own by clearly specifying what is needed for AS Migration.

[Sriram] Yes, good suggestion – removed the text. Done.

m5. In 4.2: “To prevent unnecessary processing load…a BGPsec speaker SHOULD NOT produce multiple consecutive Secure_Path Segments with the same AS number.  This means that to achieve the semantics of prepending the same AS number k times, a BGPsec speaker SHOULD produce a single Secure_Path Segment – with pCount of k...”  Given pCount, I’m wondering why these SHOULDs are not MUSTs, especially given the expected additional load.

[Sriram] We had thought about it. Decided to leave it as SHOULD rather than MUST. Most implementations will do it right. We thought -- just make it a strong recommendation rather than enforce strictly.

m6. Section 4.3. (Processing Instructions for Confederation Members) explains the process of adding Secure_Path and Signature segments that may or may not be used at all (given that the verification is optional), only to remove them later.  Why isn’t the process of adding Secure_Path and Signature segments optional itself (instead of just the validation)?

[Sriram] In a confederation, the update is crossing AS boundaries and ASNs of the members are included (cannot be omitted).  It was felt that it is not a good idea to have mixed signed and unsigned segments. Also, the same security risks may exit (e.g. illegal path shortening) between confed ASes as do between regular ASes.

m7. In 4.4. (Reconstructing the AS_PATH Attribute), what should happen if the Confed_Segment flag is set to zero and the most-recently added segment in the AS_PATH is of type AS_CONFED_SEQUENCE?  Theoretically this can’t occur because it means that someone accepted an update that it shouldn’t have, but please include some text about this case being an error.

[Sriram] This comment is related to m11. Added a new error check in Section 5.2 that reads, “If the update message was received from a BGPsec peer that is a member of the BGPsec speaker's AS confederation, check to ensure that the Secure_Path segment corresponding to that peer contains a Flags field with the Confed_Sequence flag set to one.” This takes care of m7 and m11.



m8. Section 5.1. (Overview of BGPsec Validation): “It is expected that BGP peers will generally prefer routes received via 'Valid' BGPsec update messages over both routes received via 'Not Valid' BGPsec update messages and routes received via update messages that do not contain the BGPsec_Path attribute…(See [I-D.ietf-sidr-bgpsec-ops]…”  I read this piece of text as saying that routes in Not Valid updates are expected to be used (even though they are not valid).  Besides the fact that I-D.ietf-sidr-bgpsec-ops does recommend using Not Valid announcements (in Section 7), are there other reasons for this document to expect their use?

[Sriram] If only a ‘Not Valid’ update is available for a prefix, then the update is used since otherwise the prefix would be unreachable. Both BGPsec and RPKI/origin validation are expected to depref invalid updates rather than ignore them. This is driven by operator policy and can vary. Hence, we are deliberately not using any normative language here.

m9. Section 5.1 contains these references: “…the trusted cache could deliver the necessary validity information to the BGPsec speaker using the router key PDU [I-D.ietf-sidr-rtr-keying] for the RPKI-to-Router protocol [I-D.ietf-sidr-rpki-rtr-rfc6810-bis].”   The reference to I-D.ietf-sidr-rtr-keying seems to be related to the “router key PDU”, but that is defined in I-D.ietf-sidr-rpki-rtr-rfc6810-bis, so it looks like the first reference is not needed.

[Sriram] Yes. Fixed.

m10. In 5.1: “As discussed in Section 4, when a BGPsec speaker chooses to forward…, it SHOULD be forwarded with its BGPsec_Path attribute…”   That “SHOULD” is pointing at a fact, not acting normatively in this sentence so please change it to “should”.

[Sriram] Yes. Fixed.

m11. Section 5.2. (Validation Algorithm) mentions this check: ‘update..from a peer that is not a member of the BGPsec speaker's AS confederation, check to ensure that none of the Secure_Path segments contain a Flags field with the Confed_Sequence flag set to one.”  I’m sure that the check for the flag set if the peer is a Confederation peer is also needed, but not mentioned in this section (where the normative MUST for the validation algorithm) is present.  Section 4.3. (Processing Instructions for Confederation Members) does say this: “…when a confederation member runs the algorithm in Section 5.2, the confederation member, during processing of a Signature Segment, first checks whether the Confed_Sequence flag in the corresponding Secure_Path segment is set to one.”   I would like to see the full algorithm specified in one place (even if, like in Section 4.3, pieces of it are explained elsewhere).  Also, the text in 4.3 says that the check is performed “during processing of a Signature Segment”, which is fine, but probably late in the process (compared to the text in 5.2 that seems to require the check when the updates are received).

[Sriram] Thanks for catching this. It is all fixed now. Wording changes have been made in Section 4.3 to say that the check is made during error checking rather than “during processing of a Signature Segment”. Also, in the error checking list in Section 5.2, we have added a new check that reads: “If the update message was received from a BGPsec peer that is a member of the BGPsec speaker's AS confederation, check to ensure that the Secure_Path segment corresponding to that peer contains a Flags field with the Confed_Sequence flag set to one.”

m12. In Section 7.4. (Additional Security Considerations), please add a reference to point at “appropriate transport security mechanisms.”, and/or point at the Security Considerations from rfc4271.

[Sriram] Done.

Nits:

n1. In several places the text uses “we” (for example: “we expect…”).  It’s just a matter of style, but using the third person may be more appropriate (for example: “it is expected…”).

[Sriram] Done. Changes made per your suggestion.

n2. The use of “Target AS Number” is inconsistent: sometimes the “number” is capitalized, others it isn’t, and sometimes it is not even mentioned.

[Sriram] Now the document used ‘Target AS Number’ consistently.

n3. I don’t think we need Section 6.2. (Extensibility Considerations).

[Sriram] Leaving it as is for now. Can be removed later if there seems greater conviction about it during the IESG review process.