Randy: Hi! Thanks for working on this document!
I have two issues I want to highlight upfront, and then some comments (below). I would like to see these two issues addressed, along with the Major comments below, before moving the document forward. These two upfront issues are probably more questions for the Chairs/Shepherd. 1. Why is this document a BCP? A BCP is a document that describes “the community's best current thinking…on what is believed to be the best way to perform some operations” [rfc2026]. This document meets that bar of the description, but there is clearly not a lot of practice behind the considerations – which I think is reflected in the lack of significant comments from the WG. I would prefer if this document as Informational, pending some actual experience. But I’ll settle for a good explanation (to be also included in the Shepherd’s write-up) of why BCP. 2. This document, as a companion of draft-ietf-sidr-bgpsec-protocol, is the only place where Operational (or Management) Considerations are discussed. However, important items recommended in RFC5706 (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions), such as migration or fault management are not covered anywhere. Given the tone and current content of this document, I don’t think extending it is the way forward -- so, in my review of draft-ietf-sidr-bgpsec-protocol [1], I asked the authors to include an Operations and Management Section there and to consider using this document as the base. Merging this document into draft-ietf-sidr-bgpsec-protocol is an action that the WG/authors/Chairs/Shepherds should consider. While that is my preferred solution, I will move forward with publication of this document if that is the consensus. Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/sidr/UOSfI4drrFvnO7271ivU3j9RFm4 Major: M1. In Section 5, you wrote: “As they are not formally verifiable, an eBGP listener SHOULD NOT strongly trust unsigned security markings such as communities received across a trust boundary.” After reading this piece of text several times, I think I picked up on the subtle message: don’t trust unsigned *security markings* -- vs what I got from the first n-1 readings: don’t trust communities. I think that this paragraph would greatly benefit from more details or an example related to security markings. M2. In Section 7. (Routing Policy): “As BGPsec will be rolled out over…a long time. Hence a normal operator's policy SHOULD NOT be overly strict, perhaps preferring Valid paths and giving very low preference, but still using, Not Valid paths.” This recommendation concerns me because “Not Valid” talks directly to the fact that the announcement is, well, not valid – vs just unable to be verified (because there’s no BGPsec_Path attribute, for example). The next sentence is a reflection of my concern: “Operators should be aware that accepting Not Valid announcements…will often be the equivalent of treating them as fully Valid.” I-D.sidr-bgpsec-protocol suggests the same thing (in 5.1, pointing to this document). I am left with the question: why validate at all if the BCP recommendation is to use all announcements no matter the state? I obviously realize that it is still early days – maybe it is too early for a BCP document if the “practice” is not there yet… M3. Also in Section 7: “…signed paths that are Not Valid and yet propagated…SHOULD have their signatures kept intact…” Section 4.2. (Constructing the BGPsec_Path Attribute) of draft-ietf-sidr-bgpsec-protocol says: “a Signature_Block which is not deemed 'Valid'…such Signature_Blocks MUST NOT be removed.” The “SHOULD” in this document is at odds with the “MUST NOT” in the BGPSec spec; please s/SHOULD/MUST, or (even better) s/SHOULD/should. M4. Still in Section 7: “To prevent exposure of the internals of BGP Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a Confederation MUST NOT sign updates sent to another Member-AS of the same Confederation.” This is another case where the BGPSec spec says something different: Section 4.3. (Processing Instructions for Confederation Members) presents a mandatory mechanism that includes signing, but not necessarily validating. BTW, if the updates are not signed, then the signed path would be broken, even if all the routers in the path support BGPSec, right? Is that the recommendation? M5. In Section 8: “…routers' clocks MUST be correct…” What does this mean? Correct with respect to what? Later (2 paragraphs) you do mention RFC5905, should that be the reference here? Maybe make the clock topic one paragraph to avoid confusion. References: R1. The reference to BGPsec should be draft-ietf-sidr-bgpsec-protocol (and not I-D.ietf-sidr-bgpsec-overview). I think it is ok to reference I-D.ietf-sidr-bgpsec-overview in the Suggested Reading as an Informative reference. Similarly, rfc6480, rfc6481 and rfc6482 should be made Informative as well. R2. Section 7: “This implies that the route server creates signatures per client including its own AS in the BGPsec_Path and the target ASes, see 2.2.2 of [I-D.ietf-idr-ix-bgp-route-server].” I think this reference is not correct because I-D.ietf-idr-ix-bgp-route-server doesn’t say anything about BGPSec. That section does say the opposite: “the route server SHOULD NOT prepend its own AS number to the AS_PATH segment nor modify the AS_PATH segment in any other way”. Maybe point at 4.2 of draft-ietf-sidr-bgpsec-protocol instead. R3. RFC6811 should be a Normative reference. Minor: m1. The IPv4 examples in Section 7 should use addressed from rfc6890. m2. In Section 7: “Therefore, unless local policy ensures otherwise, a signed path learned via iBGP MAY be Not Valid.” That “MAY” is not normative in this context, but it is stating a fact: s/MAY/may. m3. Also in Section 7: “If it is known that a BGPsec neighbor is not a transparent route server, and the router provides a knob to disallow a received pCount (prepend count, zero for transparent route servers) of zero, that knob SHOULD be applied.” There are other cases when pCount 0 is ok, draft-ietf-sidr-as-migration for example. I know that “SHOULD” allows other cases, but maybe working in the router server as an example might be an improvement. m4. Section 9. (Security Considerations): “The major security considerations for the BGPsec protocol are described in [I-D.ietf-sidr-bgpsec-protocol].” Are there other security considerations not mentioned there? Nits: n1. Introduction: “…origin validation…will occur over the next two to three years and that BGPsec will start to deploy well after that.” Recommendation: avoid specific timeframes, be a little vaguer (short/medium/long term). I noticed that the first version of draft-ymbk-bgpsec-ops also mentioned “two to five years” (in 2011!). n2. s/ client cone, i.e. an RR client or the transitive closure of their customers' customers' customers' etc./ client cone, i.e. an RR client or reachable transitively through one of them. n3. “As the vast majority (84%) of ASs are stubs, and they announce the majority of prefixes…” A reference would be nice. n4. “Because of possible RPKI version skew…” I guess you mean lack of sync… n5. Security Considerations. Please write something along the lines of: “This document describes operational considerations for the deployment of BGPsec. The security considerations for BGPsec are…”
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
