Subject: Re: [sidr] RPKI <-> allocation consistency

From: Stephen Kent <[email-masked]>
Date: Tue, 04 Sep 2012 10:38:17 -0400

Brian,

So, based on your reply, I guess the answer is to my question re the FSM 
you would like to see
re the RPKI is "no."

Also, the RIPE docs are not RFCs, and what we're talking about are IETF 
docs, ultimately RFCs,
so the comparison is not relevant in terms of what one should 
expect/demand of SIDR WG products.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 04 Sep 2012 10:39:05 -0400

Exclusivity cannot be enforced via RP processing of the RPKI, because of 
INR transfers,
and a "make before break"  INR transfer policy. RFC 6480 alludes to 
"make before break"
in its discussion of ROAs, though not in the context of INR transfers.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Tue, 4 Sep 2012 12:43:00 -0400

Sorry, have to call B.S. on this one.

Make-before-break is fully possible with exclusivity.

Exclusivity enforced at the CA level still allows for multiple ROAs (and
thus multiple announcing AS).

Changing (or adding, in case of anycast) ASNs requires new_ROA, new BGP
announcement, and (optionally) deletion of old ROA (or update ROA to
exclude moved INR).
(These would be two or more ROAs under control of the same party, to which
the INR had been assigned.)

If an INR needs to be moved from one party to another (e.g. transfer, such
as sale of INR), that kind of doesn't correspond to "live transfer", does
it?

And even if it does, the two-phase changes would be, new_ROA (signed by old
CA) with new_ASN, and new_new_ROA (signed by new CA) also with new_ASN.
When the parent (or parent^n) moves the INR delegation, a new validation
path replaces the old one. The fact that both new_ROA and new_new_ROA
provide validation paths for new_ASN origination of the INR, means either
way, validation continues to work.

BGP is stateful, so there isn't any substantial risk of problems. At worst,
a BGP flap during the move and/or sync issues across delegation boundaries
(from RP perspective) suggests that live transfers should occur during
maintenance windows.

This also suggests that "punting" on the requirements towards publication
points creates operational issues.
These risks could be eliminated by a requirement for atomic state-change
associated with changes to published data (e.g. *nix-style "mv" which is
atomic at the filesystem level, is well-known and widely implemented.)

IMHO, but with facts + math to back this up. Zorn's Lemma, Axiom of Choice,
anyone? FTW.

Brian

On Tue, Sep 4, 2012 at 10:39 AM, Stephen Kent <[email-masked]> wrote:

> and a "make before break"  INR transfer policy. RFC 6480 alludes to "make
> before break"

---

From: Stephen Kent <[email-masked]>
Date: Tue, 04 Sep 2012 13:55:13 -0400

Brian,
> Sorry, have to call B.S. on this one.
unsportsman-like comment, 15 yards and loss of a down.
> Make-before-break is fully possible with exclusivity.
In the general case, the resources are transferred between two CAs, and 
these CAs need not be
ISPs, e.g., they might be RIRs. So, before an ISP can issue ROAs for the 
newly-received INRs,
the ISP has to have these INRs added to it's CA cert. If the parent of 
that CA was not the parent
for the ISP that previously held the resources, then it too has to have 
the INRs in question added
to its cert, and so on. Thus means that, in general, there will be more 
that one CA, at corresponding
tiers of the RPKI, that will have the same INRs in their 3779 
extensions. Equivalently, this means
that some CA will have issued certs to two of its children, where the 
certs overlap (wrt the INrs
being transferred).
> Exclusivity enforced at the CA level still allows for multiple ROAs 
> (and thus multiple announcing AS).
Since this is not just a ROA question, I am ignoring the parts of your 
message that focus on ROAs, or on
BGP details that seem to be the result of this (confused) focus.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Tue, 4 Sep 2012 15:08:13 -0400

On Tue, Sep 4, 2012 at 1:55 PM, Stephen Kent <[email-masked]> wrote:

> tiers of the RPKI, that will have the same INRs in their 3779 extensions.
> Equivalently, this means

Let's work a straw man example.

First, the assumptions:
(1) We have existing delegations, CA_1A -> CA_1B -> CA_1C
(2) The 3779 extensions of each of these includes some INR, call it
INR_A.B.C.D/N (with exact match on each delegation)
(3) The whole of INR_A.B.C.D/N is being moved somewhere else
(3a) IMPORTANT => No "hole" in an original INR is going to exist, i.e.
there does not exist some A.B.C.E/(N-M) which covers A.B.C.D/N, which is an
INR in the 3779 of CA_1A, CA_1B, or CA_1C.
(4) It is possible to update a {CA, manifest, CRL} set to replace an
earlier instance of {CA, manifest, CRL} which includes the same set of
INRs, with different INR delegations. This is the basic mechanism for
allocation or reaping INRs.
(5) Moving an INR from CA_X to CA_Y, where CA_X and CA_Y are both children
of CA_W, is possible in a single move (using step (4) mechanics).

In all of the following, if the letter N appears in an object's name, it
means the 3779 extension includes A.B.C.D/N.

First, step by step, create new CA objects and "move" the INR up the tree
using them in an iterative fashion:
CA_1A->CA_1B->{CA_1C', CA_1CN} where CA_1CN contains *only* INR_A.B.C.D/N,
and CA_1C' no longer has A.B.C.D/N in its 3779.
CA_1A->{CA_1B', CA_1BN}
{CA_1A', CA_1AN} (signed by CA_1A's RIR or by root TAL)

Now, move the INR to the new CA parent, and then move it down the tree to
its final location (each X' is X plus 3779 addition of A.B.C.D/N):
{CA_2A, CA_2AN}
CA_2A'->{CA_2B, CA_2BN}
CA_2A'->CA_2B'->{CA_2C, CA_2CN}

And finally merge the new INR with its new owner's main CA:
CA_2A->CA_2B->CA_2C' (with CA_2C' being CA_2C plus 3779 addition of
A.B.C.D/N)

I think the above steps can be reduced to one move, where the original INR
is removed from CA_1A and added to CA_2A, as long as all the descendants of
CA_2A already had the INR included (but not validating since the
parent-most CA didn't yet have the INR in the 3779 extension).

-----

However, if there *is* a need for the old parents to cover the INR, then
the semantics are missing explicit hole-punching.

Hole-punching is needed to disambiguate overlapping certs, so as to assure
RPs the uniqueness of INRs.

A "hole" is the positively-asserted proven non-existence of permitted
matching INRs, and need to be "glued" to matching (covering) INRs wherever
INRs are delegated.

Let me know if I need to go into more detail on "hole" semantics.

(Holes are less common today than they were 15 years ago, but they are
still critical to any kind of resource validation methodology, to avoid the
entire hijacking issue.)

Brian

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Sep 2012 13:24:22 -0400

Brian,

Sorry I didn't reply sooner.

I found it very difficult to follow the details of your example, but I 
think there is a higher
level consideration that makes moot a detailed analysis of optimization 
the you suggest.

In the early days of RPKI design I raised the same question that you did 
re allocation uniqueness,
and suggested that we include RP checks for overlapping allocations in 
RP software. I was told (by operators) that the old INR holder and the 
new INR holder would each need to have certs (and ROas) that are valid, 
and that encompass the INRs being moved, and that persist for some time. 
That is a fundamental reason that the RPKI does not specify that the 
allocations are "unique." The term "unique" used to appear in the text 
of several of the docs, but was removed to accommodate INR transfers.

I think the primary concern is that one cannot be confident how quickly 
all RPs will acquire all RPKI data.
Thus it seems prudent to allow for the old and new INR holders to have 
certs that contain the INRs being transferred, for these certs overlap 
in validity, and for both certs to be available via the repository 
system at the same time, for some overlap period. This enables old and 
new ROAs, which may point to the same ASN, to exist, avoiding the need 
for a flag day.

Steve

---

From: Robert Loomans <[email-masked]>
Date: Thu, 13 Sep 2012 09:16:10 +1000

On 13/09/2012, at 03:24, Stephen Kent <[email-masked]> wrote:
> I found it very difficult to follow the details of your example, but I think there is a higher
> level consideration that makes moot a detailed analysis of optimization the you suggest.
> 
> In the early days of RPKI design I raised the same question that you did re allocation uniqueness,
> and suggested that we include RP checks for overlapping allocations in RP software. I was told (by operators) that the old INR holder and the new INR holder would each need to have certs (and ROas) that are valid, and that encompass the INRs being moved, and that persist for some time. That is a fundamental reason that the RPKI does not specify that the allocations are "unique." The term "unique" used to appear in the text of several of the docs, but was removed to accommodate INR transfers.
> 
> I think the primary concern is that one cannot be confident how quickly all RPs will acquire all RPKI data.
> Thus it seems prudent to allow for the old and new INR holders to have certs that contain the INRs being transferred, for these certs overlap in validity, and for both certs to be available via the repository system at the same time, for some overlap period. This enables old and new ROAs, which may point to the same ASN, to exist, avoiding the need for a flag day.

There are related scenarios regarding operational changes even without transfers.

Currently APNIC, for example, only provides a hosted environment for RPKI for our members. They have a web interface from which they can ask for ROAs to be created and published, and we run all of the machinery for them and publish the results in our repositories.

In the future we may allow our members to run their own RPKI installation, connecting to our RPKI service using the provisioning protocol.

I suspect they would prefer to be able to run their new RPKI installation and the hosted service simultaneously for some time, allowing relying parties to pick up the new objects, before switching off the hosted service.

Similarly, when someone wants to wholesale replace their RPKI infrastructure with a new implementation they may choose to run old and new side-by-side.

Rob

-- 
Robert Loomans                         email:       [email-masked]
Senior Software Engineer, APNIC        sip:    [email-masked]
http://www.apnic.net/                  phone:         +61 7 3858 3100

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Sep 2012 13:01:57 -0400

On Wed, Sep 12, 2012 at 7:16 PM, Robert Loomans <[email-masked]> wrote:

> RP software. I was told (by operators) that the old INR holder and the new
> INR holder would each need to have certs (and ROas) that are valid, and
> that encompass the INRs being moved, and that persist for some time. That
> is a fundamental reason that the RPKI does not specify that the allocations
> are "unique." The term "unique" used to appear in the text of several of
> the docs, but was removed to accommodate INR transfers.
> >
> certs that contain the INRs being transferred, for these certs overlap in
> validity, and for both certs to be available via the repository system at
> the same time, for some overlap period. This enables old and new ROAs,
> which may point to the same ASN, to exist, avoiding the need for a flag day.
>
> Currently APNIC, for example, only provides a hosted environment for RPKI
> for our members. They have a web interface from which they can ask for ROAs
> to be created and published, and we run all of the machinery for them and
> publish the results in our repositories.
>

I'm not familiar with what APNIC does currently.

Is it "repository" or "repositories" (plural)? Do members have their own
(hosted) repositories and CAs, or is there just one CA and a flat
repository with ROAs but no CAs?

>
> In the future we may allow our members to run their own RPKI installation,
> connecting to our RPKI service using the provisioning protocol.
>
> I suspect they would prefer to be able to run their new RPKI installation
> and the hosted service simultaneously for some time, allowing relying
> parties to pick up the new objects, before switching off the hosted service.
>

I suspect the fundamental problem is how the RPKI was "engineered" from a
specification standpoint, where the "loosely coupled" aspect was inserted
(rather than intrinsic to all possible RPKI designs), probably as a
consequence of not specifying that the notion of "time" had to be accurate
at an RP to within some specific delta of global GPS/UTC time.

For instance, prepublishing objects with validity start/end times, would in
theory be sufficient to trigger RPs to pick up objects before the start
time, and specifying (in the protocol docs) an overlap window maximum,
would achieve adequate support for transitions (of any particular purpose
and/or duration, modulo "rules" for relevant use cases).

And in particular, the transition use-case sequence would be: "pre-publish"
-> (long time) -> "enable new" -> (short window controlled by end/start
datetime in objects) -> "disable old" -> (long time) -> "unpublish old"

>
> Similarly, when someone wants to wholesale replace their RPKI
> infrastructure with a new implementation they may choose to run old and new
> side-by-side.
>
>
Architecturally limiting duplicates to dual-CAs at the same publication
point, would support this without weakening the global RPKI  security
model. All the other ways duplicates are supported, implicitly, weakens the
security model.

Brian

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Sep 2012 16:43:46 -0400

Brian,

Tp paraphrase an old joke, we've established what kind of engineers we 
are, we're just haggling over the overlap interval.

Your proposal includes a period when old and new INR holders have valid 
credentials, i.e., an overlap of valid RPKI objects. I didn't see any 
indication in your message of a proposed max overlap interval. Currently 
we no specified max overlap,so both approaches really overlap, so to speak.

You suggested pre-publication of signed objects with validity start stop 
time. Since you are discussing the current RPKI design, I presume that 
you are familiar with the syntax of certs, CRLs, and RPKI signed 
objects, as specified in the RPKI RFCs. So you realize that certs and 
ROAs and manifests all contain validity intervals already. Thus one 
could pre-publish instances of the objects involved in an INR transfer, 
as you suggested, consistent with the standard syntax. of course, all of 
these pre-published objects are invalid until the validity start time.

We make use of the RFC 5280 certificate path validation rules, as 
augmented by the 3779 extension processing (as per RFC 3779). 
Certificate path validation as per 5280 will cause the certificates that 
are not yet valid to be rejected until they become valid, and thus 
objects that are validated by these certs, e.g., ROAs and manifests, are 
similarly invalid until that time. So, pre-publication would allow one 
to push out certificates to the new INR holders prior to them being 
"activated." That could be used to reduce the contribution to the 
overlap interval that is attributable to the time we allow for RPs to 
fetch RPKI data.One would have to persuade RPs to not discard such 
not-yet-valid objects, within a reasonable time window, but that might 
be done. (One has to limit the window, since none of these objects can 
be validated and that creates a DoS vector ...)

Ifwe allow a reasonable time for RPs to have fetched the not-yet-valid 
objects, then when they "turn the crank" to process local caches after 
the objects have become valid, the RPs would accept them. But, I've 
never hear anyone suggest that one ought to try to impose a global, 
coordinated, RPKI object processing time on all RPs. (That, in itself 
would be a security concern.) So there may be limits here as to how much 
the overlap can be reduced by this strategy.

Also, are there any other examples you can cite where every network 
operator is expected to perform some activity, at the same time 
(relative to UTC), every day, around the world? What is the accepted 
norm for clock sync among all ISPs today, and what processes rely on the 
extant precision and accuracy of synchronized clocks at all ISPs? Not 
being an operator, I really don't know the answers to these questions.

Anyway, if we were to adopt your suggestion, the benefit might be that 
the overlap interval need be determined primarily by the time needed to 
accommodate skew in RPs posting, fetching, and processing RPKI objects. 
Rather the overlap interval would be a function of what  folks consider 
to be a comfortable interval to accommodate human processes (and errors) 
for the INR transfers.

I don't know that this time scale as being one that requires carefully 
coordinated clocks at all RPs, especially since we don't have a 
candidate overlap interval value on the table. Moreover, since there is 
an overlap interval in either case, it's not immediately clear how hard 
we should work to reduce it. What overlap interval did you envision?

Steve

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Sep 2012 11:50:50 -0400

I'm not sure which operators you talked to, but I think you may have
conflated two different issues that are both relevant, but which have
different requirements (or semantics, if you will).

One issue is, the transfer of *live* networks. I'm not sure there is a
strong requirement to support this per se, and/or whether limited support
for this (with limited overlapping validity periods) would suffice.
If you recall, BGP is stateful, so if the origin ASN of the INR does not
change, the RP cache latency vs "refresh" BGPSEC instances, would be the
primary risk. (Network events are a secondary risk.)

However, IMHO, live networks might change their AS path, but have no reason
to change their location in the INR allocation tree.

On the other hand, non-live transfers are the norm, and do need to be
accounted for.
And this is where, IMHO, the current RPKI design is GROSSLY flawed. Sorry
to be the bearer of bad news.

Here is the typical INR policy on transfered or returned blocks:

   - Put the returned/transfered block in the "free" pool.
   - If previously used, put a "time-out" on the block to prevent it being
   allocated for some non-trivial period. (e.g. 3-6 WEEKS)
   - Once time-out expires (if there is any timeout), make available for
   allocation
   - Allocate per normal allocation mechanisms/policies.

So, not only is there no live transfer, there is an explicit gap in the
period of usage. This means that any old caches can be purged of the INR
references (via CA or EE+ROA).
And subsequent to that, an INR allocation of previously used space, is no
different from INR allocation from a never-before-used space.

While the details (e.g. time frames) belong in an ops document, the
exclusivity requirement does need to be handled within the RPKI & RP
architectures. Currently it is not.

Brian

On Wed, Sep 12, 2012 at 1:24 PM, Stephen Kent <[email-masked]> wrote:

> and suggested that we include RP checks for overlapping allocations in RP
> software. I was told (by operators) that the old INR holder and the new INR
> holder would each need to have certs (and ROas) that are valid, and that
> encompass the INRs being moved, and that persist for some time. That is a
> fundamental reason that the RPKI does not specify that the allocations are
> "unique." The term "unique" used to appear in the text of several of the
> docs, but was removed to accommodate INR transfers.
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Sep 2012 13:07:12 -0400

On Tue, Sep 4, 2012 at 3:08 PM, Brian Dickson <[email-masked]
> wrote:

>> certs overlap (wrt the INrs
Re-replying to focus on one specific, MAJOR deficiency: INR transfers (in
the real world) vs limitations of RPKI (inherited from its use of 3779)
cannot be reconciled with the scalability and security requirements for
origin validation (and consequently BGPsec which presumes origin
validation).

> still critical to any kind of resource validation methodology, to avoid the

Let us consider what 3779 is able to represent in terms of INR values.
(As co-author, you should be familiar with this -- I'm just explicitly
re-stating for everyone else.)
It allows IPv4 or IPv6 (and/or v4/v6 representations within other AFI/SAFI
types).
For those types, it allows one or more prefixes and/or ranges.
A prefix is X/N (where X is an IPv4 or IPv6 network, and N is the number of
bits in the network portion of the address).
A range is A-B where A and B are both addresses, and B>=A.

RFC 3779 can only express positive assertions.

This is the big problem, in the context of RPKI, when handling INR
transfers.

There is no way to correctly express INR transfers of subordinate address
blocks, without drastic implications on either security, or on the ability
to efficiently announce prefixes.

Current IANA and IRR policies allow for the transfer (e.g. sale) of INRs
between parties which are constituents of different IRRs, or between
parties which are constituents of a single IRR.
These policies allow for the transfer of INRs of flexible size, including
subordinate blocks.
The policies (rightly so) discourage unnecessary fragmentation of INRs.

So, to make this issue easier to follow, lets take a fictional example
(using RFC1918 space per standard practice a la example.com) and show the
problem that results.

Let's say someone had a right-to-use on 10.0.0.0/8.
Now suppose they want to transfer (sell) a /24 out of this space, to an
unrelated party.
(Since binary trees don't have any particular affinity, the choice of /24
is both arbitrary and irrelevant for this example.)
For illustrative purposes, suppose that it is 10.20.30.0/24.

Regardless of how long the transfer takes to process, and how long it takes
RP caches to sync up, at some point in the future, the RPKI needs to
represent the "new world order".

So, what ways does 3779 support encoding of both the original block (minus
the /24), and the new block?
The new block is easy - it is 10.20.30.0/24. The new owner could be in the
same IRR, or a different IRR. The new owner would announce, in BGP (and
BGPSEC), 10.20.30.0/24.

What about the old block?
It must be encoded in one of 4 ways:

   1. 10.0.0.0/8
   2. two ranges (10.0.0.0-10.20.29.255 and 10.20.31.0-10.255.255.255)
   3. a bunch of prefixes (16 in total) of lengths 9 through 24
      1. 10.0.0.0/12
      2. 10.16.0.0/14
         1. 10.20.0.0/20
         2. 10.20.16.0/21
         3. 10.20.24.0/22
         4. 10.20.28.0/23
         5. 10.20.31.0/24
         6. 10.20.32.0/19
         7. 10.20.64.0/18
         8. 10.20.128.0/17
      3. 10.21.0.0/16
      4. 10.22.0.0/15
      5. 10.24.0.0/13
      6. 10.32.0.0/11
      7. 10.64.0.0/10
      8. 10.128.0.0/9
   4. even larger number of prefixes that form any sort of binary
   decomposition of the above 16 prefixes

However, the RP/RPKI rules mean that it is not possible to have the
original owner advertise 10.0.0.0/8, if methods 2, 3, or 4 are used.

On the other hand, restricting INR transfers to methods 2, 3, or 4, result
in each INR causing the need for an additional (N-M) prefixes, if the
original prefix length is M and the transfered prefix length is N.

And lastly, if method 1 is used, it is impossible to prevent the original
owner from producing an ROA that would validate, which covers the
"transfered" INR.

This creates a Hobson's choice: either accept the inability to protect
against subsequent (accidental or malicious) hijacking of transfered INRs,
or accept the need for routing table bloat.

===== ALTERNATIVES =====

There is an alternative - replace 3779, and the rules of inheritance in the
RPKI, with something that supports "holes".

What is a hole? The definitive assertion of the non-routeability (or
non-ownership) of longer prefixes within a block.

This would need to be "glued" onto a parent block, and remain attached to
any delegation of a block containing the "hole".

Prefixes shorter than the "hole" would be valid (e.g. an ROA with maximum
prefix length < prefix length of enclosed hole(s)).

Prefixes the same size or longer than the "hole" would be invalid. Neither
a CA (delegation) nor an ROA would be permissible if it covered the range
of a "hole" without including the explicit hole, or made permissible a
routing announcement anywhere inside the "hole".

Examples of "new world order" allowable ROAs of a hypothetical 3779-bis
would be:
10.0.0.0/8 le 23  => would allow covering prefix 10.20.30.0/23 (which is
shorter than 10.20.30.0/24) but not allow conflicting prefix 10.20.30.0/24
10.128.0.0/9 le 32 => has no overlap with the "hole" at 10.20.30.0/24
10.20.32.0/19 le 32 => has no overlap with the "hole"
10.20.31.0/24 le 32 => adjacent to, but no overlap with, the "hole"
10.20.29.0/24 le 32 => adjacent to, but no overlap with, the "hole"
10.20.0.0/16 le 23 => covers "hole", but only permits prefixes shorter than
(covering) the "hole"

In this alternate representation scheme, any necessary prefixes by either
party could be registered (in RPKI) via ROAs, and announced, without
presenting either a security risk to either party (of hijacking) or placing
a burden on the global BGP table (of prefixes dictated by RPKI
fragmentation of parent blocks of transfered INRs).

The old owner could (continue to) announce 10.0.0.0/8.
The new owner could announce 10.20.30.0/24.
Nobody would have to worry about conflicting announcements of
10.20.30.0/24(or longer).

The current RPKI scheme cannot represent this, because RFC 3779 cannot
represent this.
And as a consequence, it is impossible to encode in origin validation
logic, so RPs are not able to enjoy the benefits.

Until such a fix is implemented (in 3779, all the RPKI documents that
incorporate 3779, and all the RP-related docs), the only reasonable
conclusion is that these are fatal flaws (from the perspective of
operators).

Brian

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Sep 2012 14:31:44 -0400

On Thu, Sep 13, 2012 at 4:43 PM, Stephen Kent <[email-masked]> wrote:

>  Brian,****
>
>
>  If  we allow a reasonable time for RPs to have fetched the not-yet-valid
> objects, then when they "turn the crank" to process local caches after the
> objects have become valid, the RPs would accept them. But, I've never hear
> anyone suggest that one ought to try to impose a global, coordinated, RPKI
> object processing time on all RPs. (That, in itself would be a security
> concern.) So there may be limits here as to how much the overlap can be
> reduced by this strategy.
>

I'm not suggesting polling-based, synchronous processing of anything.
Clearly, that would be foolish.

While the implementation is up to the implementer(s), I'd expect
event-driven scheduling of processing of changes of state. E.g. set up
queues ordered by start or end date/time.

Recall, this validation is on the RPKI cache validation side. It is outside
of the scope of RPKI-RTR protocol, with the expectation that state changes
on the validation would get pushed to routers.

Pre-publishing means that local validation would merely need to occur in
the overlap window. As long as the new and old objects have been pushed to
the router with any amount of overlap, there is no risk of validation
failure on received updates.

> ****
> operator is expected to perform some activity, at the same time (relative
> to UTC), every day, around the world?
>

NETWORK operator? No. But there are plenty of other activities driven by
certificate expirations, either passively or actively, which require
overlapping (pre-published) objects in order to avoid validation failure.
DNSSEC, TLS/SSL, pretty much any certificate-based protocol or security
mechanism.

>  What is the accepted norm for clock sync among all ISPs today, and what
> processes rely on the extant precision and accuracy of synchronized clocks
> at all ISPs?
>

NTP, stratum 3 or better.

BGP neighbors normally expect each others' clocks to be NTP synchronized,
for reasons of trouble-shooting instances of accidental or malicious
issues. Logs are useless if their time is not accurate to the millisecond.
(Some peering contracts actually require this.)

Transit relationships typically require accurate measurement of traffic,
both volumetrically  and with accurate time. Failure to implement
measurement and billing using accurate (NTP) time, is a huge liability.
Customers expect to be able to correlate their own measurements with their
providers - again, without NTP, this is likely to incur L8/L9 problems.

Additionally, virtually every network link requires accurate line-clock,
either supplied by the network, or by the end devices. Nearly all network
links and/or routers have line-clocking derived (directly or indirectly)
from Stratum-1 sources. This can be achieved in a number of ways, either
special NTP feeds, or BITS, or TTL, or via transmission gear with
integrated cesium clocks and/or GPS receivers.

Failure to have synchronized line-clocking is probably the #1 source of
network problems during implementation of peering links. Drifting clocks
will cause errors and/or outages, guaranteed.

> Not being an operator, I really don't know the answers to these questions.
>

Maybe these are questions you should have asked and gotten the answers to,
prior to designing the RPKI? (Sorry, cheap shot.)

> ****
>
> Anyway, if we were to adopt your suggestion, the benefit might be that the
> overlap interval need be determined primarily by the time needed to

Overlap times are only required when there is "live transfer" of INRs,
correct? So, mostly (>>99.99999% of the INRs will never have this issue, as
99.999% won't transfer, and of the transfers, 99.99% won't be "live") moot.

So, even supposing that such incidents occur, there are two limits to
consider:
(1) The minimum (actual) overlap interval between the old and new
(2) The proscribed maximum overlap interval beyond which one or the other
should be rejected

So, the discussion would really need to focus on lower bounds and upper
bounds for (2).
Lower bounds impact mandatory actions by cache operators, or alternatively,
risk to operators/RPs of RPKI-induced outages
Upper bounds impact the security of the system, and/or window of
opportunity for hijacking.

> Rather the overlap interval would be a function of what  folks consider to
> be a comfortable interval to accommodate human processes (and errors) for
> the INR transfers.****
>
> ** **
>
> I don’t know that this time scale as being one that requires carefully
> coordinated clocks at all RPs, especially since we don't have a candidate
> overlap interval value on the table. Moreover, since there is an overlap
> interval in either case, it’s not immediately clear how hard we should work
> to reduce it. What overlap interval did you envision?
>

To paraphrase Vin Diesel (in pretty much any movie he's been in):
"Not my problem."

What I envision is, the authors of SIDR I-Ds/RFCs proposing intervals, and
then discussing/justifying them.

Brian