Re: [Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-lta-use-cases-05: (with COMMENT)

Randy Bush <> Tue, 30 April 2019 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5B6F1202CC; Tue, 30 Apr 2019 09:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CwH3LKwLDh9S; Tue, 30 Apr 2019 09:24:36 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54BF412008D; Tue, 30 Apr 2019 09:24:36 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.90_1) (envelope-from <>) id 1hLVYV-0006XR-Ia; Tue, 30 Apr 2019 16:24:31 +0000
Date: Tue, 30 Apr 2019 09:24:30 -0700
Message-ID: <>
From: Randy Bush <>
To: Barry Leiba <>
Cc: Adam Roach <>, The IESG <>,, Chris Morrow <>,,
In-Reply-To: <>
References: <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-lta-use-cases-05: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Apr 2019 16:24:38 -0000

>> Please consider adding the boilerplate specified in RFC 8174.
> Or, alternatively (and my preference), re-word that brief paragraph in
> the Security Considerations so that it doesn't use "MUST".  I find
> "Hence they MUST be implemented to assure the local constraint." hard
> to understand anyway, so re-wording might help.

as mirja kühlewind pointed out, that paragraph was a bungle.  how about

6.  Security Considerations

   Though the above use cases are all constrained to local contexts,
   they violate the model of a single Global RPKI, albeit to meet real
   operational needs.  Hence the result must be able to be validated as
   if the changed data were part of the validatable Global RPKI while
   including the local context, perhaps with the addition of trust
   anchors or authenticatable patching of trust.

   Modification 'recipes' may lack authentication.  E.g., if
   modifications to the tree are passed around a la SLURM files, see
   [RFC8416], what was object security becomes, at best, transport
   security, or authentication by other trust domains such as PGP.