Re: [sidr] WGLC: draft-ietf-sidr-origin-ops

Danny McPherson <danny@tcb.net> Mon, 14 November 2011 22:57 UTC

Return-Path: <danny@tcb.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 3361C1F0CAC for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 14:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level:
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yeAkUJir-JA for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 14:57:42 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id BA5171F0C77 for <sidr@ietf.org>; Mon, 14 Nov 2011 14:57:40 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 7D665268081; Mon, 14 Nov 2011 15:57:40 -0700 (MST)
Received: from [172.16.6.19] (122.147.35.3 [122.147.35.3]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Nov 2011 15:57:40 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=122.147.35.3; client-port=17212; syn-fingerprint=65535:44:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <20111114133704.72C05654865@minas-ithil.hactrn.net>
Date: Mon, 14 Nov 2011 17:57:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <45A556D4-F367-4193-A418-7993AF42A0EC@tcb.net>
References: <CAL9jLaaOm_=W85r3P990A6DtROTcQwSJ-KBRzAi9ugw1Bo1_cQ@mail.gmail.com> <E4B4DE52-BBB3-4FA0-A75A-B51824BA83E7@lacnic.net> <m2hb3a7uqp.wl%randy@psg.com> <m2fwiu7uji.wl%randy@psg.com> <CAL9jLabcaLnBbZXbNf7Lbv+ppm-h9yO+wBHunG4s1=emOyM6=w@mail.gmail.com> <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <m21utbfbhb.wl%randy@psg.com> <48A7C4A7-7FFB-44CB-ABCA-76E148AE0574@castlepoint.net> <20111114133704.72C05654865@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.1084)
Cc: sidr@ietf.org
Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 14 Nov 2011 22:57:43 -0000

On Nov 14, 2011, at 8:37 AM, Rob Austein wrote:

> Ultimately, the problem is the same as distributing DNSSEC TAs, or any
> other TA for that matter.  Pretty much by definition, these things
> have to be configured outside the automated system, because they're
> the bootstrap data.  Inclusion in distributions of software using the
> system seems to be the most common way, but one could envision other
> methods (T shirts handed out at IETF or *OG meetings, publication in
> major newspapers, perhaps as QR codes, invent your own mechanism --
> the key point is that grounds for believing the TAL come from outside
> the system we're trying to bootstrap).

However, in the interim (until we have a single RPKI root), the origin-ops 
draft should provide some guidance about how an RP should have the 
capability to verify "look-aside" (ugh) what resources an "INR" holds, and 
recommend that they only accept associated RPKI data for those 
resources.  The onus cannot be on the RP to resolve this themselves at 
on a global scale.

The model where each of the TAs in the TAL can assert what it is they're 
authoritative for is even mode broken than the browser/SSL/CA issues 
that we're trying to fix with DANE (the attacker at least has to be on-path 
there, before they consult a compromised CA).

Furthermore, pending the outcome of the discussion in the other thread
I started related to this topic and local TAs, the origin-ops draft should also 
include some discussion about multiple parties involved in LTA-esque 
functions (or extra TALs with "constraints") to preserve inter-domain 
connectivity during putative RPKI override/bypass functions for source, 
destination, and intermediate networks.

-danny