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

From: [email-masked]
Date: Wed, 05 Feb 2014 15:55:15 -0800

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/

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 6 Feb 2014 00:28:20 +0000

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)

Local Trust Anchor Management: http://tools.ietf.org/html/draft-ietf-sidr-ltamgmt-08

Suspenders: http://tools.ietf.org/html/draft-kent-sidr-suspenders-00

--Sandy, speaking as one of the wg co-chairs
________________________________________
From: sidr [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Wednesday, February 05, 2014 6:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-00.txt

Abstract:

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Feb 2014 11:12:56 +0900

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

if you accept the three cases of the use cases draft, you may be left
thinking that neither ltam nor suspenders meets the needs.  it's all
about roas, certs are incidental.

randy

---

From: David Mandelberg <[email-masked]>
Date: Thu, 06 Feb 2014 13:53:57 -0500

On 2014-02-05 21:12, Randy Bush wrote:
>> The question is whether we need both efforts, or only one, and if 
>> so,
>> which one.
>

I think Suspenders meets Carol's use case. Carol could publish a LOCK 
and INRD as a precautionary measure. Then when the Dutch court attacks, 
relying parties that use Suspenders would detect the attack and could 
continue to route to Carol.

I'm working on a new draft called SLURM (Simplified Local internet 
nUmber Resource Management) that I hope to have out before the cutoff 
next week. I'm pretty sure it handles Bob's use case, and I think it 
could also handle Alice's use case if I understand that case correctly.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: 马 迪 <[email-masked]>
Date: Sat, 8 Feb 2014 00:03:57 +0800

David,
	Ever since LTAM was designed, I have been intrigued by one of its motivation that a nation can protect nets within its administrative jurisdiction by directing internal nets to rely on a national authority for RPKI data for these critical infrastructure resources. I think it’s a significant concern in deploying RPKI worldwide.  As you know, I was trying to figure out how to utilize LTAM or Suspenders especially where NIRs exist.  I am therefore looking forward to seeing your new draft called SLURM that is going to bring some new ideas.

Di Ma
Internet Domain Name System Beijing Engineering Research Centre (ZDNS)

在 2014年2月7日，上午2:53，David Mandelberg <[email-masked]> 写道：

> I think Suspenders meets Carol's use case. Carol could publish a LOCK and INRD as a precautionary measure. Then when the Dutch court attacks, relying parties that use Suspenders would detect the attack and could continue to route to Carol.
> 
> I'm working on a new draft called SLURM (Simplified Local internet nUmber Resource Management) that I hope to have out before the cutoff next week. I'm pretty sure it handles Bob's use case, and I think it could also handle Alice's use case if I understand that case correctly.
> 
> 
> 
> --

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sat, 8 Feb 2014 15:33:44 +0100

Hi,

> 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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Feb 2014 13:27:20 -0500

Randy,

I have attached a PDF with edits and comments on the use cases I-D.

The current use case definitions (Section 4) don't always provide a 
clear statement of the problem
to be solved, and the requirements that a solution must exhibit. The 
Notes (Section 5) assume
characteristics of the solution space that may not be necessary; they 
certainly are not justified
by the cases as currently described in Section 4.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Feb 2014 13:55:10 -0500

Tim,
> Looks like a good starting point to me. Though I had to parse the line 
just twice ;-) ? The text needs work to be clear, precise, and a lot 
less cutesy.
> 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.
> 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 t…
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-dow…
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* attac…
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.
> 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