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

Alissa Cooper <> Thu, 05 January 2017 14:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C00312954E; Thu, 5 Jan 2017 06:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
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: (amavisd-new); dkim=pass (1024-bit key) header.b=goL4hf39; dkim=pass (1024-bit key) header.b=q0sUVF3x
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GmkBEhOIfB0w; Thu, 5 Jan 2017 06:22:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0B7B1293F3; Thu, 5 Jan 2017 06:22:29 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 4E7C620B77; Thu, 5 Jan 2017 09:22:29 -0500 (EST)
Received: from frontend2 ([]) by compute7.internal (MEProxy); Thu, 05 Jan 2017 09:22:29 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; 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=; 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 (unknown []) by (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 <>
In-Reply-To: <>
Date: Thu, 5 Jan 2017 09:22:26 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
To: Randy Bush <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: The IESG <>,
Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jan 2017 14:22:31 -0000

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


> 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