Re: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-00.txt
Stephen Kent <kent@bbn.com> Mon, 10 February 2014 18:55 UTC
Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0DF1A0128 for <sidr@ietfa.amsl.com>; Mon, 10 Feb 2014 10:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level:
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
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 e8I_q-sQWgha for <sidr@ietfa.amsl.com>; Mon, 10 Feb 2014 10:55:13 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 89A681A03A5 for <sidr@ietf.org>; Mon, 10 Feb 2014 10:55:11 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:35266 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1WCw0d-000FYo-0v for sidr@ietf.org; Mon, 10 Feb 2014 13:55:11 -0500
Message-ID: <52F9208E.20500@bbn.com>
Date: Mon, 10 Feb 2014 13:55:10 -0500
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: sidr@ietf.org
References: <20140205235515.22408.47624.idtracker@ietfa.amsl.com> <24B20D14B2CD29478C8D5D6E9CBB29F6940A848A@HSV-MB001.huntsville.ads.sparta.com> <F8D5F608-853E-47BE-9C0F-F54C4208E04F@ripe.net>
In-Reply-To: <F8D5F608-853E-47BE-9C0F-F54C4208E04F@ripe.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-00.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Feb 2014 18:55:17 -0000
Tim, > Looks like a good starting point to me. Though I had to parse the line > about unicorns twice.. just twice ;-) ? The text needs work to be clear, precise, and a lot less cutesy. >> Local Trust Anchor Management: http://tools.ietf.org/html/draft-ietf-sidr-ltamgmt-08 > If I understood correctly it was the authors intent to replace the existing ltamgmt document with the new work? Yes, with two new docs. David Mandelburg is submitting a doc to deal with the easiest cases, and I think he will request a slot to present that doc, plus a doc on address space transfer. >> Suspenders: http://tools.ietf.org/html/draft-kent-sidr-suspenders-00 > Fundamentally I think there is a problem in letting a child refer to a third party that can override its parent. I think it just doesn't fit in the hierarchical rpki, and hence all the complexity to deal with history, and trying to separate noise from signal. I appreciate that it's well intended and a lot of thought has gone into this, but in my opinion this is a very complicated way to deal with this. I am a firm believer in the hierarchic PKI. But, that said, I do think we need a credible solution to the concerns raised by folks who worry about errors or compelled actions by RIRs or ISPs. Suspenders proposes a fallback strategy to address these concerns. But, if we can develop a simpler solution, after we agree on use cases, that's great. > What I would suggest instead is to go to the third party directly. I think we already have all the building blocks.. If one goal is to not undermine the hierarchy, then we want constraints on what a third party can assert. Suspenders limits the third party to preserving the status quo; it can turn back the clock, but it can't make arbitrary statement that will be accepted by RPs (if they follow the spec). > This third party can publish a TAL containing resources that it claims to know better. They can then operate a normal CA and publish all the ROAs they see fit, or even act as parent CA using up-down. RPs could be configured to use both TAs and treat them as complementary (i.e. accept the ROAs from both), or exclusive (i.e. ignore the ROAs for the resources listed by third party under any other TA tree), or probably best even: alert the operator and let them choose and set defaults. That is precisely the sort of design that has the potential to undermine the hierarchy. And it seems to head in the direction of the awful Web PKI we have today. > To deal with Carol's case, well-known third parties could be set up. If all is well they should have no content, but the key difference is that it would no longer be possible to do a *covert* attack on Carol. I understand that it's re-active rather than pro-active, but I think this is enough to make the attack moot: it's not very effective and it has drawbacks: it degrades trust and thereby security of internet infrastructure. The attack on Carol is not covert; every RP will see it. The only question is what RPs should do in response. Allowing Carol to publish info that makes it clear that she doesn't agree with the changes to her RPKI data is probably the least dangerous way to provide RPs with the info from which they can make a decision. > Bob can just create a complementary TAL for the private space. > > Alice can create a TAL that takes precedence, and have her management's vision of the truth. > > All this needs some tooling, but I don't think it needs more standards. > The message I just posted noted that several of the use cases need clearer statements of the problems being addressed, and a less colloquial tone. So I won't comments on how we should address the other use cases until we have agreement on them. Steve
- [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-… internet-drafts
- [sidr] FW: I-D Action: draft-ietf-sidr-lta-use-ca… Murphy, Sandra
- Re: [sidr] FW: I-D Action: draft-ietf-sidr-lta-us… Randy Bush
- Re: [sidr] FW: I-D Action: draft-ietf-sidr-lta-us… David Mandelberg
- Re: [sidr] I-D Action: draft-ietf-sidr-lta-use-ca… 马 迪
- Re: [sidr] I-D Action: draft-ietf-sidr-lta-use-ca… Tim Bruijnzeels
- Re: [sidr] FW: I-D Action: draft-ietf-sidr-lta-us… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-lta-use-ca… Stephen Kent