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

Christopher Morrow <morrowc.lists@gmail.com> Wed, 28 March 2012 12:53 UTC

Return-Path: <christopher.morrow@gmail.com>
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 2CBE421E8210 for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 05:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.553
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6ZuPlYE-Knu for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 05:53:17 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA321E81DE for <sidr@ietf.org>; Wed, 28 Mar 2012 05:53:17 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so706345ggm.31 for <sidr@ietf.org>; Wed, 28 Mar 2012 05:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.60.9.38 with SMTP id w6mr36742323oea.41.1332939196941; Wed, 28 Mar 2012 05:53:16 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:53:16 -0700 (PDT)
In-Reply-To: <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> <45A556D4-F367-4193-A418-7993AF42A0EC@tcb.net>
Date: Wed, 28 Mar 2012 08:53:16 -0400
X-Google-Sender-Auth: 2IH8e_UZ8OWxGZ8UqLEp8L_wbgY
Message-ID: <CAL9jLabJ-Qoz3rByJNN8Rang7pc9F196=sM3eJhVvLhjo3Eq6Q@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Danny McPherson <danny@tcb.net>, Randy Bush <randy@psg.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Rob Austein <sra@hactrn.net>, 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: Wed, 28 Mar 2012 12:53:18 -0000

Reviving a zombie thread...
So,
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.

-chris
<cochair>

On Mon, Nov 14, 2011 at 5:57 PM, Danny McPherson <danny@tcb.net> 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr