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

Randy Bush <randy@psg.com> Wed, 04 January 2017 16:46 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A618F1299AF; Wed, 4 Jan 2017 08:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcEaS7o-aGOV; Wed, 4 Jan 2017 08:46:10 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7036A12999E; Wed, 4 Jan 2017 08:46:10 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cOohU-0002OW-BQ; Wed, 04 Jan 2017 16:46:08 +0000
Date: Thu, 05 Jan 2017 01:46:05 +0900
Message-ID: <m2inpulqnm.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "Alissa Cooper" <alissa@cooperw.in>
In-Reply-To: <148354694377.12928.12337719277813930522.idtracker@ietfa.amsl.com>
References: <148354694377.12928.12337719277813930522.idtracker@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/5-ICe3xYuNBxg_KN-7qq5yXJCDk>
Cc: The IESG <iesg@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2017 16:46:12 -0000

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