> "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.
> 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.
> "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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
