Re: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-00.txt

Hi,

On Feb 6, 2014, at 1:28 AM, "Murphy, Sandra" <Sandra.Murphy@parsons.com> wrote:

> The lta-use-cases draft was motivated as a way to start/guide discussion of the Local Trust Anchor Management draft and the Suspenders draft.
> 
> The question is whether we need both efforts, or only one, and if so, which one.
> 
> So we need to discuss the use cases.  And discuss the two drafts.
> 
> Local Trust Anchor Use Cases: http://tools.ietf.org/html/draft-ietf-sidr-lta-use-cases-00  (below)

Looks like a good starting point to me. Though I had to parse the line about unicorns twice..

> 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?

> 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.

What I would suggest instead is to go to the third party directly. I think we already have all the building blocks..

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.

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. 

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.

Tim

> 
> --Sandy, speaking as one of the wg co-chairs
> ________________________________________
> From: sidr [sidr-bounces@ietf.org] on behalf of internet-drafts@ietf.org [internet-drafts@ietf.org]
> Sent: Wednesday, February 05, 2014 6:55 PM
> To: i-d-announce@ietf.org
> Cc: sidr@ietf.org
> Subject: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.
> 
>        Title           : RPKI Local Trust Anchor Use Cases
>        Author          : Randy Bush
>        Filename        : draft-ietf-sidr-lta-use-cases-00.txt
>        Pages           : 5
>        Date            : 2014-02-05
> 
> Abstract:
>   There are a number of critical circumstances where a localized
>   routing domain needs to augment or modify its view of the Global
>   RPKI.  This document attempts to outline a few of them.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-lta-use-cases/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-sidr-lta-use-cases-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr