Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

[Randy Bush <[e-mail]>]

>    "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