great review. thanks! > 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.
because it is, as you quote, the community's best current thinking…on what is believed to be the best way to perform some operations as to significant comments from the wg, welcome to sidr; it's either a poolpah or silent assent. > 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. sidr has been separating protocol from ops all the way down the line, e.g. in origin validation. heck, you have separated (protocol == sidr) from (ops == sidrops). > 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. BGPsec does not sign over communities, so they are not formally trustable. Additionally, outsourcing verification is not prudent security practice. Therefore an eBGP listener SHOULD NOT strongly trust unsigned security signaling, such as communities, received across a trust boundary. > 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… this is the result of a primrose path and, as i am a naggumite, i am quite willing to be strict here. but how we got here was; paths are either valid or not; you do not know if it is not valid because of lack of current rpki data or an attck (much blood spilled here). once you have swollowed this reduced signaling koolaid, you could have a not valid path because you just don't have the data, a weaker state than failure. this left us wussing out on what to do with them in best path choice. how about s/SHOULD NOT/MIGHT NOT/? or, as i am a naggumite, i am willing to say just drop the suckers, and blame it on you :) > 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. Because of possible RPKI version skew, an AS Path which does not validate at router R0 might validate at R1. Therefore, signed paths that are Not Valid and yet propagated (because they are chosen as best path) should have their signatures left intact and MUST be signed if sent to external BGPsec speakers. > 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? it is common for a bgp confederation to include private ASs for which there can be no unique authorative router credentials in the rpki. hence i am suspicious of the protocol spec. > 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. As a router must evaluate certificates and ROAs which are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour. The common approach is for operators to deploy servers that provide time service, such as [RFC5905], to client routers. > 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. ack > 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. A route server is usually 'transparent', i.e. does not insert an AS into the path so as not to increase the AS hop count and thereby affect downstream path choices. But, with BGPsec, a client router R needs to be able to validate paths which are forward signed to R. But the sending router can not generate signatures to all the possible clients. Therefore a BGPsec-aware route server needs to validate the incoming BGPsec_Path, and to forward updates which can be validated by clients which must therefore know the route server's AS. This implies that the route server creates signatures per client including its own AS in the BGPsec_Path, forward signing to each client AS, see [I-D.ietf-sidr-bgpsec-protocol]. The route server uses pCount of zero to not increase the effective AS hop count, thereby retaining the intent of 'transparency'. > R3. RFC6811 should be a Normative reference. ack > Minor: > m1. The IPv4 examples in Section 7 should use addressed from rfc6890. can't. need more than a /24. we went through this in origin validation. > 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. ack > 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. If it is known that a BGPsec neighbor is not a transparent route server, or is otherwise validly using pCount=0 (e,g, see [I-D.ietf-sidr-as-migration]), and the router provides a knob to disallow a received pCount of zero, that knob SHOULD be applied. Routers should disallow pCount 0 by default. > 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? uh, none come to mind with only one cuppa. > 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!). well, we were using the ipv6 time service, clearly a mistake :) BGPsec, [I-D.ietf-sidr-bgpsec-protocol], is a new protocol with many operational considerations. It is expected to be deployed incrementally over a number of years. As core BGPsec-capable routers may require large memory and/or modern CPUs, it is thought that origin validation based on the RPKI, [RFC6811], will occur over some years and that BGPsec will start to deploy after that. > 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. In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec enabled if and only if there are eBGP speakers in their client cone, i.e. an RR client or the transitive closure of a client's customers' customers' customers' etc. > n3. “As the vast majority (84%) of ASs are stubs, and they announce > the majority of prefixes…” A reference would be nice. lost in time. removed. should rerun measurement, but not today. > n4. “Because of possible RPKI version skew…” I guess you mean lack of > sync… i don't think so. i take lack of sync meaning i can not reach a cache or publisher. version skew could occur when timers have not yet fired. but it's fuzzy. > 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…” 9. Security Considerations This document describes operational considerations for the deployment of BGPsec. The security considerations for BGPsec are described in [I-D.ietf-sidr-bgpsec-protocol]. i do not plan to push the button until you and chairs say we're converged. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
