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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 04 Jan 2017 08:22:23 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-sidr-bgpsec-ops-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 5 =

"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. I'm assuming what is
meant here is that Route Reflectors MUST NOT enable BGPsec unless there
are eBGP speakers in their client cone -- that might be a more sensible
way to phrase this since clearly enabling BGPsec isn't required for
anyone. Also, 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).

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Jan 2017 01:46:05 +0900

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

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 Jan 2017 09:22:26 -0500

> On Jan 4, 2017, at 11:46 AM, Randy Bush <[email-masked]> wrote:
> 

Ok, after reading it a few times I get it.

>    i.e. an RR client or the transitive closure of a client's customers.

Sounds good.

> 6810 advises quite the opposite.

Ok, fair enough.

Alissa