On 12/2/16, 10:56 AM, "Randy Bush" <[email protected]> wrote:
Randy: Hi! I’m fine with your comments, proposed text. Just a couple of more replies below. Thanks! Alvaro. … > > 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 :) “naggumite” – it took me a while to figure this out… ;-) My biggest problem with the original text is the normative “SHOULD NOT”, so changing that to “might not” works for me as you’re describing a fact of what may happen in the initial deployments… I am also happy to take the blame for dropping invalid stuff. ;-) … > > 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. As luck would have it, the protocol spec is in IETF Last Call right now. ;-) Short of changing the spec, we can’t have conflicting behavior being specified. … > i do not plan to push the button until you and chairs say we're > converged. Except for the Confederations point above, I think we are. Thanks! Alvaro.
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
