Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

["Alvaro Retana (aretana)" <[e-mail]>]

On 12/2/16, 10:56 AM, "Randy Bush" <[e-mail]> 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.