Re: [Sidrops] trying to limit RP processing variability

[Tim Bruijnzeels <[e-mail]>]

> On 17 Apr 2020, at 00:48, George Michaelson <[e-mail]> wrote:
> 
> If a ROA object can be removed and a manifest proves it has been
> removed, and a CRL confirms it has not been revoked, the unknown
> question is:
> 
> * what was the semantic intent of the ROA?
> 
> If you have a previously acquired state of the ROA which meets the
> manifest checksum/sig and its not in the current CRL *ITS NOT MISSING*
> and you know its semantic intent. All is good. This is what
> maintenance of local cached state of fetching achieves.
> 
> If you do NOT have a previously acquired state of the ROA, you cannot
> know its semantic intent. Job showed me that this means a covering
> aggregate ROA state which is superceded for a specific prefix can be
> invalidly interpreted as applying to the more specific. Any more
> specific. The semantic intent of unknown amounts of ROA covered space
> defined at this level in the CA hierarchy cannot be stated
> categorically because the missing ROA might modify any of them.
> 
> Therefore, the ROA states of this level of the hierarchy and children,
> cannot be known categorically.
> 
> IFF (and the FF is important) you don't have a valid ROA state cached,
> and you can detect from valid CRL and valid Manifest some ROA is
> missing, you cannot know how it modifies the routing intent in the ROA
> otherwise unaffected.

IFF.. I had to look that one up.. it stands for 'if and only if', right?

> 
> I think therefore, you have to stop processing. But the IFF part is,
> if you do not have a valid prior-state fetch of the ROA. Just because
> "its missing" is not sufficient. If the one you have before refetch
> maches what the Manifest says is a signed state, you aren't missing
> anything.

Well, I think I agree and it's what I have been trying to say. If an object is missing on a specific synchronisation job, but you still have an old copy: you know the URL, you know the hash. So if a current MFT refers to it, you can just use it.

A thought I had on this is that RPs may consider treating withdraws (be it rsync or rrdp) with prejudice. One could argue that an RP should only forget an object seen when it has seen a positive statement that it's no longer relevant:

Object becomes relevant:
- CA cert signs MFT listing object by URI and hash
- The object matching the URI and hash is retrieved (rsync or RRDP, it does not matter how)

Object becomes irrelevant:
- CA cert signs a new MFT where the object URI and hash combination is removed; AND
- The object was indeed validly signed under the CA cert
  (otherwise you open a poisoning window, I could list and delist your objects)

So, do not just remove the object because of rsync '--delete' or a withdraw or update (publish with hash) seen in RRDP. Wait for a signed confirmation.

However, I understand that this will introduce quite some complexity that may not work with existing implementations. There may also be other, better ways. For example you could keep a reference counter of MFTs referring to an object by URI and hash, and delete the object only once:
- it was marked for deletion (RRDP) and
- the reference count is zero.

Well at this point I should probably leave it to the people who write the actual validation software to say something sensible - or shout at me if you will. Just trying to contribute, don't mean to tell you how to code :D

Tim


> 
> -G
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops