[Ndn-interest] Ndn clock synchronization requirements

[Mosko, Marc <mmosko@parc.com>]

SignatureTime and SignatureSeqNum are both in the current NDN spec.  SignatureTime has been around since the beginning.  I am not sure when SignatureSeqNum was introduced.  SignatureTime may be used both in signed Data and signed Interest.

The SignedInterest spec (http://named-data.net/doc/NDN-packet-spec/current/signed-interest.html) has an explicit dependency on CurrentTime() being loosely synced (a 60 second grace period) to determine if the first interest with a key is valid, then it slides forward from that time if SignatureTime is used.

One could use a SignatureNone (and remember a nonce history) or SignatureSeqNum instead.

I agree with your premise that one should be explicit about time dependency -- which components have it and why and how can one use a alternatives if desired.

Marc


________________________________________
From: Viktor S. Wold Eide <viktor.s.wold.eide at gmail.com>
Sent: Thursday, June 13, 2019 5:26 AM
To: ndn-interest at lists.cs.ucla.edu
Cc: Mosko, Marc <mmosko at parc.com>
Subject: Re: [Ndn-interest] Ndn clock synchronization requirements

On Tue, Jun 11, 2019 at 5:07 PM Mosko, Marc <mmosko at parc.com>
<mmosko at parc.com> wrote:
>
> Another place absolute time comes into play is SignatureTime.  It is used to detect replay attacks.  There is also the option of using SignatureSeqNum instead, but that does not necessarily give any freshness information.
>
> Rather than put more effort into removing loose time sync, I think a better project would be to look at how to do good timesync over NDN so you could remove the dependency on IP-based NTP.

It is not obvious what you mean by "comes into play". Is
SignatureTime, as you refer to, used in the latest version of NDN
protocols / software to detect replay attacks? Or is this something
being considered for future protocols / software versions? Same
question goes for SignatureSeqNum.

As I wrote previously, if time sync is a hard requirement for current
NDN protocols / software to work correctly, then it needs to be stated
explicitly. Currently the stated design principle and protocols /
software seem to be in conflict. If time sync actually is (or becomes)
a hard requirement, the boundaries also need to be stated explicitly.

Note that I do not argue against doing work to develop a good timesync
protocol over NDN.

Rather, I try to get a correct understanding of the current situation
protocol- and software-wise. Does the following appear reasonable?

Either the design principle should state that loose time sync is
required. For specific protocol / software versions, the associated
time sync boundaries / limits need to be stated explicitly.

Or the Nnd core protocol and software should not depend on absolute
time, i.e., clock synchronization.

Best regards
Viktor S. Wold Eide