Gave this another review. Other than what I identify below, I think that this is ready to publish.
First, some comments specific to the interaction between this draft's language and draft-ietf-sidr-as-migration: Section 4 discusses behavior for iBGP speakers. It may be appropriate to include another reference to the slightly different behavior defined in sidr-as-migration (see sections 5.2 and 5.3). Also, 4.1 says that AS_Path and BGPSec_Path are mutually exclusive (must not send both, etc.) and section 4 says that routes originated to other iBGP peers should omit BGPSec attributes. I don't think that this and sidr-as-migration are in conflict, but I want to have another pair of eyes looking at it to make sure that the recommendations for iBGP peers are in sync. This includes if you think that the text in sidr-as-migration should be updated for better clarity. 5.2 item 5- pcount=0 - again, want to make sure that the way that this is treated in as-migration is not in conflict with this instruction. The idea is that any AS-migration configuration should be local to the edge router under migration, and not require configuration changes on every router in the ASN pair (old + new), but since there is a signature from old_ASN to New_ASN with Pcount=0 coming from an iBGP neighbor, this is a detail we have to have right, whether it drives changes in your text or mine. Note: after Keyur's review, I made some wording changes to section 5.2 of as-migration, but it's still in my edit buffer, so the text in the current version is replaced by: 5.2 "When a PE router receives an update from an eBGP neighbor that is locally configured with AS-migration knobs (i.e. the opposite direction of the previous route flow), it MUST generate a signature from the old (local) ASN forward signing to the new (global) ASN with pCount=0. It is not necessary to generate the second signature from the new (global) ASN because the ASBR will generate that when it forward signs towards its eBGP peers as defined in normal BGPSec operation. Note that a signature is not normally added when a routing update is sent across an iBGP session. The requirement to sign updates in iBGP represents a change to the normal behavior for this specific AS-migration implementation only." Now, some general comments: Section 5: extreme circumstances...defer validation. Perhaps we should add a recommendation that this behavior be visible (i.e. Log messages, visible in bgp diagnostic information, etc.) While the circumstances that invoke this behavior is a matter of local policy/implementation, I think it's reasonable to add this recommendation to make sure that it's visible to the operator when it is happening. Section 5.2 - elsewhere in the document (7.3), you note that validation should stop when an invalid signature is found. However, I see no mention of that in the actual validation algorithm. That seems like good practice even if there isn't a long chain of signatures to validate. Additionally, 7.1's text "Thus, a BGPsec speaker MUST completely validate all BGPsec update messages received from external peers." seems to conflict with this recommendation because it says "completely". I think it's a wording problem, i.e. We're not saying you MUST validate the *entire* update, but rather you must validate ALL updates that you *receive* until you encounter an invalid signature within a given update, in which case you can stop and move to the next update. Also, it may be appropriate to state that the application of local policy on validation state may be dependent on the ASN, i.e. I may want to say that I want to drop or depref invalid BGPSec routes but carve out a list of exception ASNs where the policy is bypassed (or vice versa). This is largely an implementation detail and probably better discussed in detail in the ops considerations doc, but it may be important in the protocol doc because it requires more info to be passed from the validation machinery to the policy machinery - in other words, it can't just know that somewhere in this update, there was an invalid signature, and thus the update is invalid, it may need to know that the update is valid except for the signature for ASN1701 in order to have granular enough policy control. Section 6.1 "It is anticipated that, in the future mandatory, the algorithm suites document will be updated to specify a transition from the 'current' algorithm suite to a 'new' algorithm suite." This sentence is pretty hard to parse, wasn't sure if it's a misplaced word or just clunky. "We anticipate that in the future, the mandatory algorithm suites document..."? Or if that was the intended word order, I think it says that we're anticipating that the algorithm suites doc will be mandatory and that it will be updated to transition to new suites. Let's be a little clearer - we already know that the algorithm suites doc will be mandatory, so we shouldn't really need to qualify this statement so much. Thanks, Wes George On 1/26/15, 5:45 PM, "Sandra Murphy" <[email protected]> wrote: >The editor of draft-ietf-sidr-bgpsec-protocol, BGPsec Protocol >Specification, indicate that all issues have been addressed and the draft >is ready for a working group last call. > >This starts a working group last call for >https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-11. > >Please review the draft and send comments to the list. Please include >whether you believe the draft is ready for publication. > >This wglc will end on 9 February 2015. > >--Sandy, speaking for the wg co-chairs This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
