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

Danny McPherson <> Mon, 14 November 2011 22:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3361C1F0CAC for <>; Mon, 14 Nov 2011 14:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.58
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5yeAkUJir-JA for <>; Mon, 14 Nov 2011 14:57:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BA5171F0C77 for <>; Mon, 14 Nov 2011 14:57:40 -0800 (PST)
Received: by (Postfix, from userid 0) id 7D665268081; Mon, 14 Nov 2011 15:57:40 -0700 (MST)
Received: from [] ( []) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by with SMTP; Mon, 14 Nov 2011 15:57:40 -0700 (MST) (envelope-from
X-Avenger: version=0.7.8;; client-ip=; 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 <>
In-Reply-To: <>
Date: Mon, 14 Nov 2011 17:57:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Rob Austein <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.