i think the plan is to shift the -ops document (this one) to the sidrops group...I meant to ask about: "how do we do that?" I'll do that in person tonight.
At Wed, 2 Nov 2016 15:35:18 +0000, "Alvaro Retana (aretana)" <aret...@cisco.com> wrote: > > 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. i think the intent of this document is to write down (document) the inteded 'best practices' for running bgpsec enabled networks. viewed in that light, there aren't any of these things out there today, but as a place to start looking and planning for deployment operations folk (me) want some guidance on what thingsto expect/do/fix as we roll out. i think bcp fits for that... much like bcp 17. I have updated the shepherds doc to reflect the above paragraph's intent/ideas. > 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 Ideally the migration is covered in the protocol document, I see it only talk about as migrations (business events), which seems ok. Migrations of keys or algorithms are covered in other documents and mentioned in this document. which migrations are you referring to? > 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 I'm not sure I'd stick more into the protocol document though, especially things which don't explicitly describe the protocol itself. I think keeping the protocol description/design in one document and the operations of the system in a seperate document isn't unreasonable. I expect the set of ops documents to change/evolve over time, I'd hate to -bis the protocol for operational work later. > 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
