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

Christopher Morrow <> Wed, 28 March 2012 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CBE421E8210 for <>; Wed, 28 Mar 2012 05:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.553
X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C6ZuPlYE-Knu for <>; Wed, 28 Mar 2012 05:53:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 70EA321E81DE for <>; Wed, 28 Mar 2012 05:53:17 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so706345ggm.31 for <>; Wed, 28 Mar 2012 05:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FgJIYV4x/2t3xRPOM7/aSvYNahOBWhOD+fDEGmUR9lc=; b=rqTfWVwvGlzz2GqqIsJzieVaGO//RmXB6rh5Rb6onUnlQpiDMZThf24RExaLwpYWKS PClI7SISPDdY0jZoD9XJJZNF598SWwYNcJDNa08rnIg2cuX9kHPsOFl4K3z6AAgPWtXO nAuBr2QeVGknA6gnR/XQkXDZZ7H9bHnGP5gR2syKXVKx+tu7i3lKUrbZ/nqzjDT6bXGv 7COb0DjFMiTrESK8fClNeXLLUDsAsXSHWdvIEyBcvBFHwAD4DNQJqGj4rpTrFi+AydLB nhQpSY4TF0BTgn2NzhqMICIVIOuqjHirn3K3AmI+Ys15c0nZ8mywtafI2DxhTd8zgaNh kphw==
MIME-Version: 1.0
Received: by with SMTP id w6mr36742323oea.41.1332939196941; Wed, 28 Mar 2012 05:53:16 -0700 (PDT)
Received: by with HTTP; Wed, 28 Mar 2012 05:53:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Wed, 28 Mar 2012 08:53:16 -0400
X-Google-Sender-Auth: 2IH8e_UZ8OWxGZ8UqLEp8L_wbgY
Message-ID: <>
From: Christopher Morrow <>
To: Danny McPherson <>, Randy Bush <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Rob Austein <>,
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: Wed, 28 Mar 2012 12:53:18 -0000

Reviving a zombie thread...
Where does this set of comments end us? Are the updates put in between
11/11 and 03/12 taking care of the discussion? or are there still
things to wrangle?

I think, given the length and breadth of discussion here we'd all do
to re-read and re-WGLC this doc once things are settled.


On Mon, Nov 14, 2011 at 5:57 PM, Danny McPherson <> wrote:
> 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
> _______________________________________________
> sidr mailing list