Subject: [sidr] Origin Ops, TALs and Local TAs

From: Danny McPherson <[email-masked]>
Date: Mon, 14 Nov 2011 16:38:42 -0500

Rob/Steve, et al., 
Relative to the SIDR Origin Ops draft and local trust anchor (LTA) 
configuration, I'm trying to understand how one would actualize 
trust anchor locators (TALs) and LTAs in a deployment scenario and 
was hoping you could help me here.

I think it's probably safe to assume everyone is going to have a 
"Constraints" file for some things.  

Because the TALs don't actually specify the list of resources covered by 
the referenced self-signed CA certificates the relying party must consult 
each trust anchor (e.g., RIR) to determine the INR extension(s) within this 
certificate, and the onus is on the RP to resolve conflicts, is this correct?
  
For example, currently, in the experimental pilot RPKI system many of the 
INRs are asserting 0.0.0.0/0 and 0::/0, which opens the opportunity for 
conflicts that must be resolved by the RP, when they likely have no real
capability to do this (hence the IAB statement on this topic).

Here's my primary question.  If I wanted to form a 'federation' of sorts for 
resiliency would I have to use additional TALs in conjunction with my
LTA and paracertificate hierarchy?  If so, can an RP include some sort of
filter to constrain what a TA can assert as within their resource holdings?

That is, because for LTA to work every relying party in the transaction 
path (i.e., source and destination networks, as well as intermediate RPs) 
would need to override the putative [global] TA RPKI for every other 
operators resources and generate a paracertificate hierarchy therein, 
is that right?

And if that's the case, wouldn't it be simpler for RPs to be able to 
associate resources with each trust anchor rather than trusting them to 
convey to the RP what resources they are authoritative for?

Does this question make sense, or is this problem solved elsewhere?

Thanks, 

-danny

---

From: Rob Austein <[email-masked]>
Date: Tue, 15 Nov 2011 07:47:54 +0800

Danny,

For purposes of this discussion, a LTA is semantically equivalent to a
collection of TAs plus a constraint list.  Since LTAs are also a more
general mechanism (they can be shared by a group of like-minded folks
more easily than a constraint list -- just create a TAL pointing at
the LTA) and since LTAs have the nice property of keeping the raw
constraint list out of the validator itself (thus keeping the
validator that much simpler), my advice to anybody who thinks they
need a constraint list would be to use a LTA.

We can discuss this further at the face to face meeting if you like,
but that's the summary as I see it at the technical layer.

Layers 8+ are mostly out of scope for this list, so let me just say
that I am really hoping that IANA and the RIRs will get their
collective act together and issue a single TA before this becomes a
serious problem.  They say that they intend to do so.  As somebody (KC
Claffy?) said a few years ago, relying parties should not have to sort
out this mess, that's what the industry pays the RIRs to do.  For the
moment I'm willing to take the RIRs' word that they intend to do their
job and just need a bit more time.  YMMV.

If that fails, well, maybe we can talk to Olaf Kolkman about having
his friend Bert sign the RPKI root.  This isn't rocket science.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 14 Nov 2011 19:02:09 -0500

> but that's the summary as I see it at the technical layer.

That'd be good, because I'm not comfortable with that as an RP.

> job and just need a bit more time.  YMMV.

Until then (or even after in the event of a CA compromise), it's a 
technical issue and the capability for RPs to determine who holds 
what resources, or at least to constrain who they trust with what 
resources, and intersect that with the LTA 'federation' issue is very
much an operational issue.

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 14 Nov 2011 22:07:03 -0500

> much an operational issue.

This is back to your (danny) point about: If someone[1] removes a
Resource Certification (ROA, for instance) and that resource is
actually critical[2] (or in use), all parties between the resource
(server) and the service-requestor (user) are bound to need to know
that the resource is still there, and valid. These parties all need to
populate their LTA (Local Trust Anchor) with the right certification
data.

This seems like it will be messy, telling everyone via some
phone-tree, and potentially confusing.
On top of that if the resource is then re-certified (to the same or
different end entity) how do the intermediate parties know which is
the 'right' thing to do?

-chris

[1]: This is the nominal 'black helicopters' problem, also seen today
via ICE or PROTECT-IP
[2]: The netblock, for instance, for the .cx ccTLD (presuming that .cx
is doing/permitting-some-actions that a third party finds
objectionable)

b: I made up the example, and the 2 'black helicopter' examples are
certainly USA-centric, we could make up many more, but ... that's not
horribly relevant. The problem could also be triggered by someone
mistakenly missing their payment window to the RIR.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 14 Nov 2011 22:57:50 -0500

> different end entity) how do the intermediate parties know which is

Agreed..  It's critical to highlight that LTA doesn't fix anything here
unless this is accommodated by all parties in the transaction path.

Furthermore, because CAs can be compromised (as we've seen with 
many CAs whose @day_job IS security), and today anyone in your TAL 
list can assert authority for any resources (as many are currently doing
currently), without the ability to filter this or scope it in some manner it
could be really problematic.

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 15 Nov 2011 00:22:28 -0500

> unless this is accommodated by all parties in the transaction path.

in one sense, LTA is meant to certify resources local to the ASN (or
set of ASNs which use the LTA, of course). It could be to cerify
'blackhole' routes, or RFC1918-like space.

in another it's been bent for the 'stop the black-helicopters' problem
(or the less controversal: 'Joe forgot to pay ARIN' case). So far your
comments, I think, are about this use-case.

> many CAs whose @day_job IS security), and today anyone in your TAL

also, we ought to be clear that the 'CA' is really one 'CA' at the
root, we hope. which is both good and bad...

> could be really problematic.

agreed, can we only have one root CA please? :) Having more than 1 is
just asinine. (imho)

-chris

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Nov 2011 02:50:53 -0500

Danny,

>was hoping you could help me here.

A TAL points to a self-signed RPKI cert, which contains a 3779 extension that
describes all of the address space under that cert. It also has an 
SIA extension that points to the repository publication point where 
one begins retrieval of other RPKI certs, etc.

>"Constraints" file for some things.

The local TA mechanism specifies that capability, but we've been told 
that most folks will find it too hard to manage that capability 
correctly.

>certificate, and the onus is on the RP to resolve conflicts, is this correct?

the TAL doesn't but the cert to which it points does. If one uses a 
TAL for IANA (consistent with the IAB recommendation that you helped 
author), then 3779 processing will catch conflicts.

>capability to do this (hence the IAB statement on this topic).

Agreed that an RIR claiming 0/0 is bad. I think this is holdover from 
the pre-TAL TA model. Hopefully this will go away.

>filter to constrain what a TA can assert as within their resource holdings?

not sure what a federation is, but, yes, an RP can constrain what a TA
is allowed to assert, via a constraints file.

>operators resources and generate a paracertificate hierarchy therein,

I don't understand all of the words above.

>convey to the RP what resources they are authoritative for?

LTA management allows this, but it becomes very complex to do well if 
there are too many data items to manage.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Mon, 21 Nov 2011 22:09:35 -0500

> is allowed to assert, via a constraints file.

Ahh, this makes good sense.

> I don't understand all of the words above.

Apologies for the loose terminology here..  Try this..

AS1 --- ISP1 (AS2) --- ISP2 (AS3) --- AS4

In the case of LTA if these four parties wish to transact their constraints files 
(or shared "non-putative" RPKI TAs) must be familiar and synchronized with
each other via some out of band mechanism - i.e., they either have to:

1) synchronize LTA contents across the set
2) share a common non-putative TA that magically does this

and in doing so, they likely would want to constrain what a TA is allowed to
assert,  via a constraints file, as noted above?

That is, LTA for the local AS doesn't fix the multi-AS/multi-administrator/RP 
issue, and so some synchronization or shared non-putative TA needs to be 
developed in they desire autonomy outside of the putative set.  

Is that correct?

> LTA management allows this, but it becomes very complex to do well if there are too many data items to manage.

Yeah, that's what I'm mulling...

Thanks, 

-danny

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Nov 2011 17:13:10 -0500

At 10:09 PM -0500 11/21/11, Danny McPherson wrote:
>...

The original model for an LTA was, as the name suggests, local, hence 
just one AS.  However, it is easy to extend that model to encompass a 
set of AS'es under the same admin control. In that case, the set of 
ASes all agree to accept the
RPKI "view" managed by some entity in control (relative to the set of ASes).

In your example are all of the ASes independent? You say that they 
want to "transact their constraints file" but you didn't say why, nor 
what the relationships might be among the constraints file for each 
AS.

The LTA constraints, as currently defined, are expressed via a set of 
local processing flags, tags, and pointers (via SKIs) to extant certs 
(sections 3.2-3.4). All of these can be shared, but that doesn't say 
what each AS would do if the values of the flags or tags differ. 
Since I'm not sure what the trust model is here, I don't know if this 
is a problem. Also, if the blocks subsection has conflicting 
directions it's not clear what each AS should do.  (A union of the 
constraints would work cleanly, but only if the affected subtrees are 
disjoint. Other attempts at forming a union of constraints could 
break, depending on the details.)

Modulo the issue of constraint conflicts, each AS can maintain its 
own LTA, and perform the re-parenting and "perforation" as directed 
by the blocks subsection of the constraints.

Does that answer your question?

Steve

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 28 Nov 2011 19:53:15 -0500

On Mon, Nov 28, 2011 at 5:13 PM, Stephen Kent <[email-masked]> wrote:
>>  > I don't understand all of the words above.
>>
> The original model for an LTA was, as the name suggests, local, hence just
> one AS.  However, it is easy to extend that model to encompass a set of
> AS'es under the same admin control. In that case, the set of ASes all agree
> to accept the
> In your example are all of the ASes independent? You say that they want to
> "transact their constraints file" but you didn't say why, nor what the
> relationships might be among the constraints file for each AS.

I think danny's example (as explained off-line in taipei) was something like:

  o 3 cooperating ASNs (say: 701, 7018, 2914)
  o one customer on either side of the 3 ASNs (a-widget-maker &&
a-widget-user/customer)
  o All have RPKI + BGPSEC deployed
  o the 'blackhelicopters of forgotten payment' arrive at ARIN's
doorstep and remove the Registration data for a-root/24.

  For a-widget-customer to still access a-widget-maker all of the
intermediate ASN's (and a-widget-customer even) will have to enter
into their LTA's some bogus/temporary certificate data... Or, I
suppose, they could just wing it on 'not validated' but still the only
prefix-in-town?

I think Danny's proposing some federation of LTAs under distributed
control where these folks all agree that "a-widget-maker/24 is still
a-ok by us!".

-chris

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Nov 2011 10:27:48 -0500

>control where these folks all agree that "a-widget-maker/24 is still

OK, that's a very helpful statement of the concern.

If the widget maker had a cert for the /24, the LTA management mechanisms
can allow the co-operating ASes to continue to use it, even after an RIR
removes it. The current spec assumes that the ASes retrieve the old cert
from their local caches to do this. We might explore (standard) ways 
to move certs to deal with the possibility that one or more of the 
ASes in question
does not have the old cert in its cache.

There are controls to allow RPs to ignore the expiration of the certs for
the widget maker, but that's not the best outcome. Ultimately the widget maker
would like to have a new CA cert issued to it, and continue to manage the'
corresponding CRL, manifest, and ROA(s). All of that can be 
accommodated using the LTA mechanisms, but it will become complex if 
there are a lot of exceptions of this sort.

Steve

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 29 Nov 2011 10:36:26 -0500

On Tue, Nov 29, 2011 at 10:27 AM, Stephen Kent <[email-masked]> wrote:
> corresponding CRL, manifest, and ROA(s). All of that can be accommodated
> using the LTA mechanisms, but it will become complex if there are a lot of
> exceptions of this sort.

I think this last bit gets at danny's concern (after the 'but every
asn in the path has to agree that the root is wrong' bit)... lots more
complexity here is not helpful :(

-chris

---

From: Danny McPherson <[email-masked]>
Date: Tue, 29 Nov 2011 10:49:24 -0500

> complexity here is not helpful :(

Yes.

-danny

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Nov 2011 11:18:06 -0500

>>  complexity here is not helpful :(

The characterization above is not quite right, but close :-).

The fundamental notion of LTA is that each RP is the "root." That's a 
good model
for PKIs in general, not just the RPKI, as it allows an RP to accept 
putative roots and impose constraints on them.  (This is the opposite 
of the browser model.) But, as in most of life, TANSTAAFL. The 3779 
extensions that help
ensure that a misbehaving CA is limited in the extent of the damage 
it can inflict on the rest of the RPKI also makes it more complex to 
use the generic LTA model.

It is accurate  to say then when an RP wants to adopt a different view of the
RPKI then there is more work involved. Hierarchies are often adopted because
they make it easier to organize and to distribute a workload. So, 
there is a tradeoff, intrinsically, when an RP wants to pick and 
choose data from a hierarchy.  If a set of ASes want to let some 
third party do all of this for them, then they could use the LTA 
mechanisms to do that, in a trivial fashion. But, that approach give 
up all local control, and so it has its own downside.

Steve