Re: [sidr] two stranded docuemnts - stake time

Tim Bruijnzeels <tim@ripe.net> Tue, 02 August 2016 08:21 UTC

Return-Path: <tim@ripe.net>
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 5290F12B035 for <sidr@ietfa.amsl.com>; Tue, 2 Aug 2016 01:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 V0xlO8nqh70R for <sidr@ietfa.amsl.com>; Tue, 2 Aug 2016 01:21:44 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4869212B004 for <sidr@ietf.org>; Tue, 2 Aug 2016 01:21:44 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bUUxJ-0001ul-Dm; Tue, 02 Aug 2016 10:21:42 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-36.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bUUxJ-0001LX-88; Tue, 02 Aug 2016 10:21:41 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="us-ascii"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <m2twf44f3p.wl%randy@psg.com>
Date: Tue, 02 Aug 2016 10:21:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD27D168-C52F-4841-8151-E109C7DE0F5B@ripe.net>
References: <yj9oinvzi8gj.wl%morrowc@ops-netman.net> <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <yj9ofur2iqgd.wl%morrowc@ops-netman.net> <m28twudtww.wl%randy@psg.com> <CAL9jLab9Zaz1UjJfjJNmjU3FcMkF+mSYKLj7VGKEydK0FKOjJg@mail.gmail.com> <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com> <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net> <67f9b7b7-d490-1671-3b30-8c1ab73d2d12@bbn.com> <78682CEF-7643-47B9-AD73-22ADC3B653C4@ripe.net> <m2twf44f3p.wl%randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: --------
X-RIPE-Spam-Report: Spam Total Points: -8.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.3696]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b170cb701ecafabaf11d3457c87eaf83
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/deuSjGkYC1indOnoCYZAmg3xdhg>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] two stranded docuemnts - stake time
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: Tue, 02 Aug 2016 08:21:45 -0000

Hi Randy,

I did. Thank you very much.

Do you think that a notice to law enforcement about how this action would be ineffective and counter-productive has a place in your analysis? Something along the lines of what I suggested earlier:

    Law enforcement would be ill-advised to take this cause of action as it will degrade the trust that
    operators place in the global RPKI. Not only can operators use local policy to circumvent the "bogus"
    objects - making it an ineffective measure, abuse of this power will also lead to operators choosing
    not to use RPKI at all. This in turn will mean that critical internet infrastructure will remain
    vulnerable to hijacks.

I never denied that there will be some in LEA that look at RPKI as a knob to control routing. But rather than raising this as a given and misquoting a different incident as legal precedence (which again it just isn't in the legal sense - freezing contact data is a far cry from changing routing), it would be much better if the analysis made it very clear to LEAs that this is a very bad idea in the first place.

They really should care more about protecting critical infrastructure, governmental, military and civil - where a lot more is to be lost in security and economic damages if the technical community turns away from this technology, than there is to be gained by black-holing some traffic - ineffectively and temporarily.

And to operators it should be clear that the use of local policy or exceptions (e.g. SLURM) can be used to easily circumvent such actions.

Tim



> On 01 Aug 2016, at 18:40, Randy Bush <randy@psg.com> wrote:
> 
> you may, or may not, notice that the current i-d does not mention
> ripe/ncc
> 
> randy