Subject: [sidr] Comments on rpki-rtr

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Jun 2011 17:46:22 -0700

Greetings again. In hopes that this document gets pushed out to IETF Last Call soon, here are a few comments that might help clear up some confusion and inconsistency in the document.

Section 2 says a serial number is:
      A 32-bit monotonically increasing ordinal which wraps
      from 2^32-1 to 0.  
Section 5.10, it says:
      An implementation
      which uses a fine granularity of time for the Serial Number might
      never change the Cache Nonce.
Which is correct? The latter is not a monotonically increasing ordinal.

Section 4 says:
   When the cache updates its database, it sends a Notify message to
   every currently connected router.
Section 6.2 says:
   The cache server SHOULD send a notify PDU with its current serial
   number when the cache's serial changes
The first is mandatory, the second is advisory; they should match.

In section 5.3, there seems to be an implicit "MUST flush all data", like the explicit one in section 5.10. It should probably be explicit here as well or, if not, the document should say why a router might not flush when getting data after a reset.

Section 5.10 says:
      If, at
      any time, either the router or the cache finds the value of the
      nonces they hold disagree, they MUST completely drop the session
      and the router MUST flush all data learned from that cache.
Why does the session need to be dropped? This could cause delay when re-authenticating. Wouldn't it make more sense for the side that discovers the problem to simply send Reset Query or Cache Reset? The same problem appears in the first paragraph of section 10.

Section 6.1 says:
   To limit the length of time a cache must keep the data necessary to
   generate incremental updates, a router MUST send either a Serial
   Query or a Reset Query no less frequently than once an hour.  This
   also acts as a keep alive at the application layer.

   As the cache MAY not keep updates for more than one hour, the router
   MUST have a polling interval of no greater than half an hour
Which MUST is correct? Half an hour or an hour? (And why are these MUST-level at all? This could be simply be an operational decision.)

In section 2, "Non-authoritative Cache" is defined but is then only used once, in section 3. Also in section 2, the definition of "cache" is not in fact a definition. Maybe get rid of these two from section 2, and pull the term "local cache" from section 3 here. 

The repeated use of "rcynic" is confusing given that rcynic will probably have features added in the future. None of them is really needed in order to describe how this protocol functions.

A non-trivial editorial issue: the draft uses "commensurate" in many places that does not match any of the definitions I can find in my dictionaries. I *think* that the draft means "the same", but that is not clear.

--Paul Hoffman

---

From: Randy Bush <[email-masked]>
Date: Fri, 24 Jun 2011 10:27:08 +0900

>       An implementation which uses a fine granularity of time for the
>       Serial Number might never change the Cache Nonce.

both are.  and this is a problem because?

the nonce is not specified to be increasing or decreasing.  it is a
nonce, not a counter.

> The first is mandatory, the second is advisory; they should match.

there is no MUST in the *overview* in sec 4.  notify is not mandatory.

> In section 5.3, there seems to be an implicit "MUST flush all data",
> like the explicit one in section 5.10. It should probably be explicit
> here as well or, if not, the document should say why a router might
> not flush when getting data after a reset.

from the currently published version -12

5.3.  Reset Query

   Reset Query: The router tells the cache that it wants to receive the
   total active, current, non-withdrawn, database.  The cache responds
   with a Cache Response PDU (Section 5.4).

i see nothing about flushing anything.  restart session, please.

> Why does the session need to be dropped?

because it is not the same session.  e.g. serials are not commensurate.

> This could cause delay when re-authenticating.

if the nonce was off i sure would want to re-auth

> Which MUST is correct? Half an hour or an hour?

good catch

> (And why are these MUST-level at all? This could be simply be an
> operational decision.)

they may be under different authorities and be different code bases.

> In section 2, "Non-authoritative Cache" is defined but is then only
> used once, in section 3. Also in section 2, the definition of "cache"
> is not in fact a definition. Maybe get rid of these two from section
> 2, and pull the term "local cache" from section 3 here.

i wonder why i was differentiating.  have removed.  thanks.

> The repeated use of "rcynic" is confusing given that rcynic will
> probably have features added in the future. None of them is really
> needed in order to describe how this protocol functions.

it is used twice, and couched in words indicating it is an example
   software such as rcynic
   for example via rcynic

> A non-trivial editorial issue: the draft uses "commensurate" in many
> places that does not match any of the definitions I can find in my
> dictionaries. I *think* that the draft means "the same", but that is
> not clear.

no.  it means drawn from the same number space.  i.e. if the nonce
differs, the cache and the router mean very different things by serial
value 42.

randy

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Jun 2011 19:25:50 -0700

> both are.  and this is a problem because?

...because the spec is inconsistent. If a router is expecting the first and the cache is doing the second, the router would decide the cache is noncompliant.

> the nonce is not specified to be increasing or decreasing.  it is a

Wearing my security pedant hat, it is not a nonce at all. It is a randomly-selected value that is used repeatedly as a selector. We agree that it is not a counter. It is not useful to change all the uses of "nonce" in this spec to something more correct.

> there is no MUST in the *overview* in sec 4.  notify is not mandatory.

Good. Then section 4 should say "database, it should send ..."

> i see nothing about flushing anything.  restart session, please.

This confuses me. What does "restart session" mean? Section 5.10 says:
      If, at
      any time, either the router or the cache finds the value of the
      nonces they hold disagree, they MUST completely drop the session
      and the router MUST flush all data learned from that cache.
That sounds like "restart session" implies "MUST flush". Being a bit more explicit in 5.3 and 5.10 would help implementations interoperate. 

> because it is not the same session.  e.g. serials are not commensurate.

OK, maybe I'm confused by what you mean by "session", and it doesn't appear to be to defined in the protocol.

> if the nonce was off i sure would want to re-auth

If you are using transport that assures integrity, there is no reason to believe that you are no longer talking to the same party just because one of you forgets the nonce or otherwise gets out of sync. What attack are you trying to prevent by doing a re-authorization?

> differs, the cache and the router mean very different things by serial

Right, but that's not what "commensurate" means. The common definition across multiple dictionaries is "proportionate" or "of similar size", and that is definitely *not* what you mean here. I don't even find your definition in my math dictionary, and the math term "commensurable" is not applicable here.

--Paul Hoffman