> On Jan 4, 2017, at 11:46 AM, Randy Bush <ra...@psg.com> wrote: > >> "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." >> >> "MUST ... if and only if" is a strange construction. > > the syntax may be stressed but the semantics are correct. > >> I'm assuming what is meant here is that Route Reflectors MUST NOT >> enable BGPsec unless there are eBGP speakers in their client cone -- > > nope. if there are no bgpsec speakers in the client cone, the RRs MAY > still choose to validate. the point is that, if there are *any* bgpsec > speakers in the client cone, then you'll want them to receive signed > paths. hence the RRs would have to enable bgpsec signing.
Ok, after reading it a few times I get it. > >> for a normative requirement I think it would be better to be specific >> rather than saying "etc." (e.g., "a client's customers or customers >> thereof" or something like that). > > how about tossing the extra words and going with > > i.e. an RR client or the transitive closure of a client's customers. Sounds good. > >> "Additionally, outsourcing verification is not prudent security >> practice." >> >> Isn't that part of the point of draft-ietf-sidr-rpki-rtr-rfc6810-bis >> though? I know this paragraph is not talking about that but since use >> of a trusted cache was mentioned in the protocol draft, this struck me >> as a slight discrepancy. > > 6810 sec 3 > > Local Caches: A local set of one or more collected and verified > caches. A relying party, e.g., router or other client, MUST have > a trust relationship with, and a trusted transport channel to, any > authoritative cache(s) it uses. > > contrast this with this document's > > 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. > > note that this document is advising not crossing a trust boundary > carrying data where integrity and authenticity are not protected, while > 6810 advises quite the opposite. Ok, fair enough. Alissa > > but if you want to stab me with outsourced security, have a look at > draft-ietf-sidr-origin-validation-signaling-10.txt. note that, while i > am a co-author, i raised my hum against adopting, progressing, ... it > was one of those rock and hard place things. > > randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
