Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation)

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Oct 2009 09:28:52 -0400

At 4:15 PM +1000 9/21/09, Terry Manderson wrote:
>On 19/09/2009, at 3:23 AM, Stephen Kent wrote:
>
>>
>>We were told over a year ago that, because of legitimate transfers, 
>>looking for duplicates was bad idea, in the repository system.  So, 
>>I'm not sure if we want to do it in the 'assimilated relying party 
>>rpki.'
>>
>
>So legitimate transfers will breed duplicates? My recollection of 
>that discussion that there would be timing in place that certificate 
>validity times would be tuned (with sparse use of CRLs) to effect 
>the transfers. Or am I mistaken?

I have been told that it is likely that certs issued in conjunction 
with transfers will overlap in validity intervals.

>I think, if anywhere you needed to go looking for duplicates it 
>would be the relying party software (either your software or rcynic) 
>before it mades it to the router "decision"

Yes, and I was referring to RP software trying to look for duplicates 
in the certs it downloads.

>>...
>
>If your software can change the contents of the 3779 extensions, 
>would it not be a simple exercise to change the SIA value?

The model for our local TA management system does not require any 
changes to SIA values, because all of the changes are purely local. 
And, as I noted, 3rd party CAs are not consistent with the CP.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Oct 2009 09:39:25 -0400

At 4:39 PM +0200 9/17/09, Andrei Robachevsky wrote:
>Stephen Kent wrote on 16-09-2009 17:53:
>[...]
>>
>>  Statements about perceived trust in TAs are useful in PKIs that anoint
>>  3rd parties as TAs, independent of real world authorization. The RPLI is
>>  not such a PKI. Instead it seeks to have the real world entities that
>>  manage allocation of resources act as CAs. I would urge us to NOT try to
>>  make the RPKI into a trusted 3rd party PKI.
>>
>
>I agree. However, I envisage a scenario when the RP in your local TA
>management scheme announces itself globally as a root CA/TA. And then
>the question arises how one can distinguish between these ersatz RPKIs
>and associated stuff (repositories, ROAs, etc.)?
>
>>  Steve
>
>Andrei

Andrie,

The local TA management mechanisms I described makes no provisions 
for advertising TAs to a larger community. Any means of doing this 
are outside the scope of the mechanism.  If an entity has the 
authority to convince other entities (in some domain) to accept it's 
vision of the RPKI, based on applying local TA management mechanisms, 
then it can do so, but how it does so it outside of the local TA 
management mechanism.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Oct 2009 09:30:37 -0400

At 3:24 PM +0400 9/21/09, Basil Dolmatov wrote:
>Stephen Kent ÔË¯ÂÚ:
>>  If folks want, I can prepare an 
>>(informational) I-D that describes_ one_ way of 
>>managing TA locally, as per my presentation at 
>>the SIDR meeting.
>
>Folks want.
>
>It would be a nice reference point and would 
>save a lot of explanations in future deployment.
>
>dol@

We will generate an I-D.

Steve

---

From: Terry manderson <[email-masked]>
Date: Wed, 7 Oct 2009 12:05:06 +1000

On 06/10/2009, at 11:28 PM, Stephen Kent wrote:

>> that discussion that there would be timing in place that  
>> certificate validity times would be tuned (with sparse use of CRLs)  
>> to effect the transfers. Or am I mistaken?
>

so two organisations, at some point in time, will have the ability to  
issue valid and conflicting statements.

I think that is really hairy. I can guess it was for the concern of  
maintaining connectivity, ie not creating break scenarios. But to me  
it appears to muddy the water. Surely there are better ways to achieve  
a low impact transfer? ie place an embargo on ROA/BOA creation for a  
time slice either side of the transfer. That would have the effect of  
degrading the trust statement, but not conflicting it nor breaking  
routing, for the period of transfer.. But still allows a clear  
delineation of 'ownership'.

Although I'm not sure if that is in the IETF bailiwick to discuss.  
Maybe since having global operations impact it is.

> And, as I noted, 3rd party CAs are not consistent with the CP.

My thoughts would be that a local TA would also run a local repository  
for itself, and any subordinate entities.

Cheers
Terry

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 07 Oct 2009 17:47:18 +0100

Terry, see below...

Terry manderson wrote:
>>> validity times would be tuned (with sparse use of CRLs) to effect the 
>>> transfers. Or am I mistaken?
>>

They have that ability today, it is being used and it's useful. Would you 
want to take that ability away from them, should they want to use RPKI?

> maintaining connectivity, ie not creating break scenarios. But to me it 
> appears to muddy the water. Surely there are better ways to achieve a 
> low impact transfer? ie place an embargo on ROA/BOA creation for a time 
> slice either side of the transfer. That would have the effect of 

Suppose you're ISP1, and want to sell some part of your clients to ISP2 
(this happens: mergers, splits, you name it). In other words, you want to 
transfer a live, routed and used chunk of space to another party. How would 
you execute this while ROAs are in place? If you think about it you'll 
realize that there have to be multiple ROAs which overlap in terms of 
validity time, otherwise you introduce exact timing, which sounds pretty 
difficult to execute with 30K+ participants.

Of course the whole story is a lot easier if you don't need to keep the 
network alive.

Robert

---

From: Jared Mauch <[email-masked]>
Date: Wed, 7 Oct 2009 13:04:14 -0400

On Oct 7, 2009, at 12:47 PM, Robert Kisteleki wrote:

>>>> certificate validity times would be tuned (with sparse use of  
>>>> CRLs) to effect the transfers. Or am I mistaken?
>>>
>>> I have been told that it is likely that certs issued in  
>>> conjunction with transfers will overlap in validity intervals.
>>>
>> so two organisations, at some point in time, will have the ability  
>> to issue valid and conflicting statements.
>
> They have that ability today, it is being used and it's useful.  
> Would you want to take that ability away from them, should they want  
> to use RPKI?
>
>> maintaining connectivity, ie not creating break scenarios. But to  
>> me it appears to muddy the water. Surely there are better ways to  
>> achieve a low impact transfer? ie place an embargo on ROA/BOA  
>> creation for a time slice either side of the transfer. That would  
>> have the effect of degrading the trust statement, but not  
>> conflicting it nor breaking routing, for the period of transfer..  
>> But still allows a clear delineation of 'ownership'.
>
> Suppose you're ISP1, and want to sell some part of your clients to  
> ISP2 (this happens: mergers, splits, you name it). In other words,  
> you want to transfer a live, routed and used chunk of space to  
> another party. How would you execute this while ROAs are in place?  
> If you think about it you'll realize that there have to be multiple  
> ROAs which overlap in terms of validity time, otherwise you  
> introduce exact timing, which sounds pretty difficult to execute  
> with 30K+ participants.
>
> Of course the whole story is a lot easier if you don't need to keep  
> the network alive.

Operators will always opt to keep their network alive, anything that  
risks keeping the network operational will have a hard time finding a  
place in networks.

I can think of other cases I'm not going to enumerate here, but  
typically transfers of customers and space take months if not years to  
sort out, while actual network control may happen more immediately.  I  
think we still have customers on "NTT" space that are homed on the  
Cogent network from some prior transfers.

- Jared

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Oct 2009 11:13:37 -0600

> another party. How would you execute this while ROAs are in place?

ISP1 would issue ROAs with ISP2 as authorized origin AS for
prefixes in question, no?

> introduce exact timing, which sounds pretty difficult to execute  

My concern isn't about collision/overlap of ROAs at the bottom
of the RPKI hierarchy, that seems perfectly reasonably to me if
the operator so chooses.

My concern is about resolution of collisions among TAs and CERTs
at the top, in particular when the TAs are NOT congruent to the
address allocation hierarchy - how does a relying party elsewhere
resolve this when the TA and allocation hierarchy are not congruent
(not to mention implications on attack surface as a result).

-danny

---

From: Terry Manderson <[email-masked]>
Date: Wed, 7 Oct 2009 17:41:03 -0700

Hi Robert,

On 8/10/09 2:47 AM, "Robert Kisteleki" <[email-masked]> wrote:
[..]
> want to take that ability away from them, should they want to use RPKI?

There are differences to what actions result from "statements" today, versus
what actions will occur in RPKI given the WG stance (which I don't agree
with) on ROA interpretation.

If you have two certificates that overlap in validity time, say for 10/8,
the following can occur:

The first certificate holder issues only a ROA for 10/8 maxLength 8 @AS1 and
originates 10/8 from AS1

The second certificate holder issues only a ROA for 10/8 maxLength 24 @AS3
and originates 10.1.1/24 from AS3 (ie some migration strategy)

Depending on which certificate the Relying Party believes, they might reject
(based on current WG interpretation of a ROA) the other valid announcements
at their router. (at least that is how I'm reading it - please correct me if
askew)

If you approach this as a 'not found' interpretation - as originally written
- this becomes near moot.

> difficult to execute with 30K+ participants.

Transferring networks (ie changing the AS origination of a prefix) and
transferring ownership doesn't need to be done at the same time. If it is I
suspect you probably won't be keeping the network alive.

The exact timing that you speak of is coordinated in advance through
notBefore and notAfter times of the two resource certificates. I would think
that in your example, assuming that only ownership is being transferred, and
not origination, ISP1 and ISP2 would make their ROAs match (or be non
existent) for the ownership settlement time as to not upset routing.

Terry

---

From: Terry Manderson <[email-masked]>
Date: Wed, 7 Oct 2009 17:46:52 -0700

> I can think of other cases I'm not going to enumerate here, but

Actually, for the benefit of the use-cases draft, could you?

> sort out, while actual network control may happen more immediately.  I

right, so "ownership" happens at a different time and space to network
origination? (That's been my experience, being in active takeovers of
companies where not upsetting the network and customers was the highest
priority - but still making sure the control was in hand)

> Cogent network from some prior transfers.

Can you elaborate in terms of ISP1 and ISP2 to protect the innocent?
Ie provide action timing? what happened when?

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Wed, 7 Oct 2009 17:56:51 -0700

> prefixes in question, no?

right.. and further make the ROAs match before and after settlement as to
not upset the network.

> of the RPKI hierarchy, that seems perfectly reasonably to me if

But what decision should the relying party make? in other words how does the
relying party know that collision was intentional?

> (not to mention implications on attack surface as a result).

I suspect, the only answer to this is a trusted TA repository that blesses
the TAs so that all the Relying Parties can at least start from a cogent
position. I can hear the groans of discomfort now.. :-)

Cheers
Terry

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Oct 2009 19:14:22 -0600

> relying party know that collision was intentional?

I'd think it wouldn't matter with the RP, if the ROAs
are there then accept those prefixes from the specified
Origin AS - even if multiple - i.e., doesn't a valid
ROA imply it was intentional ;-)

> position. I can hear the groans of discomfort now.. :-)

Indeed..

-danny

---

From: Terry Manderson <[email-masked]>
Date: Wed, 7 Oct 2009 18:23:30 -0700

> ROA imply it was intentional ;-)

Sorry, my response was poorly worded.

My position is that we probably shouldn't allow a system into play that can
produce a fully ambiguous result.

T.

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Oct 2009 19:35:31 -0600

> at their router. (at least that is how I'm reading it - please  

But they're not mutually exclusive, the RP would surely
permit both, no?

-danny

---

From: Jared Mauch <[email-masked]>
Date: Wed, 7 Oct 2009 21:35:10 -0400

> Actually, for the benefit of the use-cases draft, could you?

Take the end of EUNet as an example.  There were some kind souls that  
kept the network up and running, and there were users behind the  
network.  This space was routed by a variety of providers in the  
aftermath.  The business risks would be higher today as a result (as a  
customer) and as someone trying to capture the business in the  
aftermath, there would be incredible pressure to get things done ASAP  
to bring a new customer online, possibly with their "old" space as the  
proper owner is not around to assert control/authority/objections.

> priority - but still making sure the control was in hand)

This varies from company-to-company. I've seen it on the large telco  
scale and the small regional ISP scale over the years.  Sometimes old  
staff is laid off as part of an asset acquisition, so it's hard to  
show proper authority for a period of time with your suppliers/vendors  
(SPs/RIR, etc)...

> Ie provide action timing? what happened when?

I think that real-life examples help explain the practicality of the  
process that ends up happening.  We continue to forward security and  
abuse complaints as a part of the legacy.  That happened in December  
2004. Five years later there are still customers covered by this  
agreement.

Have to run for now, but this should help....
	- Jared

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Oct 2009 19:38:08 -0600

> produce a fully ambiguous result.

Hrmm..  You mean like the current routing system - where at
this moment I see ~2086 (same length) prefixes that have multiple
origin ASes - I'd hope that the RPKI would support AT LEAST this,
but the reality is that a layer abstracted, it's likely to need
to be considerably more flexible.

-danny

---

From: Terry manderson <[email-masked]>
Date: Thu, 8 Oct 2009 11:50:55 +1000

> But they're not mutually exclusive, the RP would surely

The relying party shouldn't have 'both' - I think having two unique  
valid resource certificates from separate or the same issuer that  
contains the same resources is flawed.

Terry

---

From: Terry Manderson <[email-masked]>
Date: Wed, 7 Oct 2009 18:53:21 -0700

> this moment I see ~2086 (same length) prefixes that have multiple

no. That is not what I mean.

> to be considerably more flexible.

The issue at hand is two different owners of a resource being able to say
different things about that resource.

Terry

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Oct 2009 20:04:44 -0600

> different things about that resource.

But that's not what I said - I said to make this work you'd
have the EE ("owner") issue two ROAs, one for each origin -
there's still only one "owner" at any given instant and that
"owner" would surely work with the acquiring or acquired entities
to accommodate such a request -- if routing the prefix(es) in
question required this.

This seems straight-forward to me..

-danny

---

From: Terry Manderson <[email-masked]>
Date: Wed, 7 Oct 2009 19:14:15 -0700

> have the EE ("owner") issue two ROAs, one for each origin -

yes. but predicated on one owner and not two. I think we are at the same
place :-)

> to accommodate such a request -- if routing the prefix(es) in

Yes.

> This seems straight-forward to me..

yes.. I think I must have misinterpreted your direction, I thought you were
wanting overlapping validity.

Terry

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Oct 2009 20:22:21 -0600

> yes. but predicated on one owner and not two. I think we are at the  

Yep, and one minor clarification here to the above: Because
there's a one-one mapping between EE certs and ROAs the
resource holder would have to issue an EE & ROA (or resource
cert and expect the recipient to issue their own EEs and ROAs
for the prefix(es), if the operator wants to loosen things up
a bit during transitions) for each prefix/origin pair) -- but
there's still only one "owner" (resource holder) at any instant
-- even though there may be multiple ASes originating a given 
prefix (or subsets).

> wanting overlapping validity.

Nope..

The issue of handling "staged ROAs for transition" and subsequent
pollution in an automated RPKI will be interesting, that's for sure..

-danny

---

From: Robert Kisteleki <[email-masked]>
Date: Thu, 08 Oct 2009 09:40:03 +0100

Danny McPherson wrote:
>> ISP2 (this happens: mergers, splits, you name it). In other words, you 
>> want to transfer a live, routed and used chunk of space to another 
>> party. How would you execute this while ROAs are in place?
> 

As a first step, yes. And then what? Ultimately, the goal is to transfer 
"ownership" of the prefix to ISP2, not jus allow them to route it. Therefore 
at some point, ISP2 itself will want to make a ROA for it. Here is when the 
timing tricks don't work.

>> ROAs which overlap in terms of validity time, otherwise you introduce 
>> exact timing, which sounds pretty difficult to execute with 30K+ 
>> participants.
> 

Ack.

> (not to mention implications on attack surface as a result).

If you accept, as above, that at lower nodes may need to have overlaps, and 
furthermore accept that allocation is hierarchical (which is the reason to 
use CAs, after all), then the logical conclusion is that the overlaps appear 
at higher levels too. Even at the "top", TA level, whoever those are.

Robert