Subject: [Sidr] On Time and Frequency of ROA Publication

From: Danny McPherson <[email-masked]>
Date: Mon, 17 Mar 2008 21:05:27 -0600

In reading draft-ietf-sidr-cp-03, and S 2.3 specifically, I have
a couple questions:
"A new ROA will be published before a predecessor ROA has expired, or  
within 24 hours after an address space holder has changed the set of  
ASes that is authorized to advertise the address blocks it holds."
What do folks believe would be normal behavior in a system if
the CA and a new ROA were not available for some extended
period of time?  For example, some natural disaster occurred?
I know an individual RP could "opt out", but that's not realistic for
Internet-wide deployment.

Second, if a new ROA is required and that information is employed
directly by the routing system and validated by a protocol such as
SBGP, would this model require that each routing entry for which
a ROA exists be readvertised every ~24 hours?  I understand how
an offline system could suppress certificate updates, but not if this
information is directly employed by the routing system itself.

Thanks!

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

---

From: Danny McPherson <[email-masked]>
Date: Tue, 18 Mar 2008 11:48:21 -0600

OK, let me clarify my questions...

Is there any guidance regarding how long a ROA should be
valid?  Geoff's BOA draft suggests that new BOA's should be
issued on a 24 hour basis.

The reason I ask is because if these are employed directly
be a secure routing protocol then the amount of churn in the
routing system as a result of periodic refreshes could be
considerable (think RIPv1 - e.g., 250k/24/60/60 = ~3 updates
per second, and that's being gratuitous).   If they're cached out
of band or employed to seed IRR objects the refreshes alone
can be suppressed.

Also, regarding this text in S 2.3 of sidr-cp-03:

     A new ROA will be published before a predecessor ROA has expired,  
or
     within 24 hours after an address space holder has changed the set  
of
     ASes that is authorized to advertise the address blocks it holds.

So here, this would require that the holder of the address space
pre-notify and provide a precise window for cutover from one origin
AS to another.  In this case, if it's actually the same entity but  
they're
migrating AS numbers or the like, would they simply certify a ROA
themselves for the other origin AS until the transition occurs?  This
is the most common case I can think of today where issues such
as this may arise.

And my question regarding availability of the CAs still stands,
although I do realize its a very operational one, I think it's one
we need to consider, and the Time and Frequency of Publication
issues above have an impact on this.  I'd particularly be interested
in hearing about how the RIR folks are planning to deal with this.

-danny

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 18 Mar 2008 14:41:47 -0400 (EDT)

>a ROA exists be readvertised every ~24 hours?

I don't see why a new ROA would necessitate a new BGP Update.

Can you say why that would be necessary?

The Update should still be in the Adj-RIB-In, and the new ROA (absent
changes in authorization, of course) should authorize it as well
as the old ROA.

--Sandy

---

From: Danny McPherson <[email-masked]>
Date: Tue, 18 Mar 2008 12:57:21 -0600

> changes in authorization, of course) should authorize it as well

Ahh, that's perhaps where I'm missing something.

So, intermediate systems validate based on the ROA and
it has a periodic expire with the associated certificate, doesn't
the refreshed certificate need to be propagated each time it's
refreshed - if employing such a capability in an inter-domain
routing protocol?

-danny

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 18 Mar 2008 15:20:53 -0400 (Eastern Daylight Time)

> refreshed - if employing such a capability in an inter-domain

That's the reason behind the need to (r)sync with databases everywhere 
periodically.  Like creating your filters from IRRs each evening.

--Sandy

---

From: Danny McPherson <[email-masked]>
Date: Tue, 18 Mar 2008 14:07:40 -0600

On Mar 18, 2008, at 1:20 PM, Sandra Murphy wrote:
>
> That's the reason behind the need to (r)sync with databases  
> everywhere periodically.  Like creating your filters from IRRs each  
> evening.

Yes, but I'm saying, IF the ROA/expiry data is included in
a secure routing protocol's route update messages and is
to be validated by intermediate systems, then such periodic
refresh timers could have considerable implications on the
stability of the routing system.

-danny

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 18 Mar 2008 16:16:27 -0400 (Eastern Daylight Time)

> a secure routing protocol's route update messages and is

Ah.  Well, that's a possible future direction, but we're not there yet.

> stability of the routing system.

In any distribution of the ROA/certs, you need to take some care in 
operational matters - creating the new cert with some overlap in validity 
timing seems desirable, getting the new ROA distributed in time whether 
through repositories or BGP or whatever, and error conditions (see Geoff's 
draft) that have a "validates but against expired ROA" case coupled with 
local policy as to whether to accept that or not, etc.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2008 17:40:53 -0400

>information is directly employed by the routing system itself.

Each resource holder is expected ton issue a ROA with a lifetime 
based on the holder's perception of the duration of the binding. For 
many (most?) folks, the binding between them and the AS authorized to 
originate a route to the prefix(es) in question is long lived, and 
the ROA (and associated cert) will be similarly long lived. However, 
as soon as the binding is no longer valid. the resource holder 
revokes the ROA by issuing a CRL. Thus the primary timeliness issue 
here is the frequency with which RPs fetch repository entries and 
discover new ROAs (and matching certs) and CRLs. The admonition to 
publish a new ROA that overlaps the old one is a way to avoid gaps 
and not require tight synchronization. Also note that a ROA 
authorizes an AS to originate a route for the prefix. One can publish 
a ROA for an AS that will originate a route only in case of an 
emergency, in anticipation of an advertisement being sent.

Steve