[Ndn-interest] Ndn clock synchronization requirements

Tue Jun 11 08:07:25 PDT 2019

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.

Marc

________________________________________
From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on behalf of David R. Oran <daveoran at orandom.net>
Sent: Tuesday, June 11, 2019 7:39 AM
To: Viktor S. Wold Eide
Cc: ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] Ndn clock synchronization requirements

Probably not a good idea to weigh in on this, but my views are well
known and I’ll take the heat for repeating them here.

On 11 Jun 2019, at 10:03, Viktor S. Wold Eide via Ndn-interest wrote:

> Dear list members,
>
> The NDN Protocol design principles state that the core network
> protocol
> operations should not depend on clock synchronization:
> https://named-data.net/project/ndn-design-principles/
>
> I do look into this from the perspective that hosts should be able to
> only
> rely on their internal clock, that is, without depending on any kind
> of
> network time protocol synchronization.
>
This is a very bad tradeoff in my opinion. We are now at the point that
our civilization will collapse if loosely synchronized absolute time
stops being available (e.g. GPS). Deciding to not depend on loosely
synchronized absolute time and using delta time and its vagaries with
respect to network latency and queueing delays (not to mention storage
delays) seriously hampers all aspects of a new protocol architecture
like NDN.

Providing such clocks is becoming cheaper and cheaper, and reasonable
for all but the lowest-end sensor/IoT devices. This problem may fix
itself as technology improves, but even if it doesn’t, it’s nearly
certain that such devices will be only one network hop away from a
reliable source of absolute time that can be fetched and adjusted
frequently enough that the bad oscillators in these devices won’t
drift out enough to matter (for things that don’t need better than 1s
or even 100ms accuracy).

With a few exceptions, NDN should switch over to absolute rather than
relative time for data expiration, key lifetimes, and cache control
directives. (CCNx has already done this). The only reasonable exceptions
are timers that operate on RTT timescales, like Interest lifetime
(assuming no long-lived interests, as some NDN things like Kite use)
where delta time does not pose a problem.

Aside from the direct NDN protocol design benefits, having reasonably
good absolute time accuracy dramatically simplifies many distributed
algorithms.

> I have been doing some testing with the Ndn software, including the
> most
> recent version of NLSR. From what I see, NLSR requires clocks on
> different
> hosts to be fairly well synchronized. The clock synchronization
> requirement
> is stated in the "Lessons from development and deployment" section in
> [1]
> from 2016 : "... This means that the network has to be roughly time
> synchronized for the protocol to work. ..."
>
> I could not see a clock synchronization requirement listed elsewhere,
> but I
> might have overlooked something.
>
> I see that the testbed page notes the following :
> Clock Skew Status: (As compared to UCLA Node's time: Green: < 5 secs
> off;
> Yellow: 5 < > 30 secs; Red: > 30 seconds off). This might be
> interpreted as
> the host clocks should be synchronized to, preferable within 5
> seconds, and
> at least within 30 seconds.
>
>> From what I understand clock synchronization is currently required
>> for the
> following:
> - certificates to be within valid range
> - NLSR LSA timeout handling
>
> This leads to the following questions:
>
> Is there anything else or in NDN core network protocol operations that
> require clock synchronization? In case, to what extent?
>
> I guess clock synchronization can be made very relaxed for certificate
> validation? For example on the order of many hours clock skew.
>
> Has anyone looked into ways to change / modify the NLSR protocol /
> software
> in such a way that it is not dependent on clock synchronization? Or at
> least not to this level of synchronization.
>
I advocate doing exactly the opposite.

>
> [1]  NDN, Technical Report NDN-0037, 2016.
> http://named-data.net/techreports.html
> Revision 1: January 26, 2016.
> https://named-data.net/publications/techreports/ndn-0037-1-nlsr/
>
>
> Best regards

> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

DaveO
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest