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

Alissa Cooper <alissa@cooperw.in> Thu, 05 January 2017 14:22 UTC

Return-Path: <alissa@cooperw.in>
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 1C00312954E; Thu, 5 Jan 2017 06:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=goL4hf39; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=q0sUVF3x
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 GmkBEhOIfB0w; Thu, 5 Jan 2017 06:22:30 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B7B1293F3; Thu, 5 Jan 2017 06:22:29 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4E7C620B77; Thu, 5 Jan 2017 09:22:29 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 05 Jan 2017 09:22:29 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=EirJYZ0QVGhTXp9 vd7Kg6dhmm84=; b=goL4hf39VxBAW3ch2CyP8RTOM91QwAdrv4v5tWqJEptwo1H ZuCZyTozCCrKvhWBFFLJqjXxIGxW4r4UybUoyQRPf82TrwtoTpaaDmSgLIqyKDT2 hx5F9oAd8wskjit6Jbhi3jZuiwV3RjwuBxtOIM2GiBmmWOg34E4ILotXBF1U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=EirJYZ0QVGhTXp9vd7Kg6dhmm84=; b=q0sUVF3xC4OCgAVWwZWZ RepupgDvwZKDQt30qgfiOdOd5HWlhXzfm+flB9U+fiYJi2snobVauBcF1Ncy09MW 2pPNOjm4g0swwiMxxhQa7gTAZtPGNShZQNxA8THzmLgc49b70MxG4ERWZpHLT+T8 klFRwR2ildFvdOmFpB0SyA4=
X-ME-Sender: <xms:pVZuWEfRIEQwcq646CtCgZ5smpw2KP4qqaXgXDsrDMwCddBmYIe69g>
X-Sasl-enc: idNP2hG5qUxFkvYxbp31ppcYvH+Mhaq/gOpk4/2rEfQq 1483626148
Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 7AB7E24077; Thu, 5 Jan 2017 09:22:28 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <m2inpulqnm.wl-randy@psg.com>
Date: Thu, 05 Jan 2017 09:22:26 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <CF59B3AA-3F48-4D18-9EA4-F040E09FBAE6@cooperw.in>
References: <148354694377.12928.12337719277813930522.idtracker@ietfa.amsl.com> <m2inpulqnm.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/T156NDwhfdX6tYXxiS8WZe5aNPs>
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: Thu, 05 Jan 2017 14:22:31 -0000

> On Jan 4, 2017, at 11:46 AM, Randy Bush <randy@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