[Ndn-interest] Time and synchronization

Alex Afanasyev alexander.afanasyev at ucla.edu
Thu Feb 5 13:45:03 PST 2015

> On Feb 5, 2015, at 1:18 PM, <Marc.Mosko at parc.com> <Marc.Mosko at parc.com> wrote:
> The NDN spec for signed interests specifically says "Note that this verification process require signed interest to be received in order. Applications adopting this process may want to take 'stop-and-wait' strategy.”  Therefore, the actual synchronization of timestamps is not essential, they are just a non-monotonic increasing sequence number.  This may or may not work for you application.
> Computing the grace interval, as specified there, does require at least loose synchronization of clocks.
>> Note that for the first Interest, the state is not available. To handle this special situation, the recipient should check the Interest's timestamp against a grace interval (e.g., 120 seconds) [current_timestamp - interval/2, current_timestamp + interval/2]. The first interest is invalid if its timestamp is outside of the interval.
> DTLS and IPsec use a sliding window, so they specifically protect against replay without enforcing ordered packet arrivals.  They use sequence numbers, not timestamps.

The reason they can use sequence numbers is because the "session" is getting authorized in the beginning with some challenge/nonce.  We probably can do something similar, but idea was to avoid any sessions that need to be established before performing the control.


> Marc
> On Feb 5, 2015, at 1:05 PM, Chaim Rieger <chaim.rieger at gmail.com> wrote:
>> Hash: SHA1
>> Followup
>> After reading
>> http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing
>> Snip...
>> valid signed Interest whose timestamp is equal or later than the
>> timestamp of the received one has been received before.
>> Note that in order to detect this situation, the recipient needs to
>> maintain a latest timestamp state for each trusted public key
>> This speaks to my question, NDN has some requirements that depend on
>> Time/Timestamp. Who is the master of said Time ? If I were to generate
>> data in the future (Time+60s) would that be read after data that is
>> generated in RealTime 30 Seconds from now ?
>> There seems to have been some minor discussion that broached this
>> subject on this mailing list back in Sept of 2014.
>> Does my question(s) make sense ?
>> On 2/5/2015 12:36 PM, Junxiao Shi wrote:
>>> Hi Chaim
>>> There isn't a timestamp on Data packet at network layer. If your
>>> application needs it, add a timestamp at application layer as part
>>> of Content.
>>> Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger"
>>> <chaim.rieger at gmail.com> wrote:
>>> When generating data that is for multicasting/distribution on an
>>> interactive level how would ndn keep track of the time across the
>>> network. Data has a requirement to be delivered and interacted
>>> with at a certain time after which it should expire or be ignored.
>>> Is there some sort of timekeeping within the NDN protocol ?
>>>> _______________________________________________ Ndn-interest
>>>> mailing list Ndn-interest at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> Version: GnuPG v2
>> YvnRPOPIlEHVThJCdzdrVYp9BkV/slXtcaenNGQmo8/84vx2UJ4dmo4b8XhfIy93
>> eKz6hgDxfMH1uS8sq5+nXJRP1fs3TKlhbJfTH6tfYk0AlAxDEAhw0DnQyD/NwbBH
>> Y53m+o6yeMf4HDIJjvGeFJfYZxeIg8+R3ocMr1VZdvClfDRryvvucjU7mLEw+9NO
>> 0xB3bn+My6ScuuR3Rspy7hssHOyJDcpZ4OkPaiMbCcUDc+GAKg1Cm1IzhL9cTj3D
>> JftYboAde5i7cZDOhh37p7ezYp12bbWRKNVvxG2DZ/Ow4CU8GWUyjgnpZdpukB2v
>> 0QGzzBryx6V9YB+8MDw+g2ljeMiHaKDnsKlm5dZSxbjAQ1axK3EecEc53r8LTjYk
>> cZ/7JVO2FlI8wAR7DKUZADA3qPpH4q4AlG1yGvfhDHKGjzeprzjX0FIy440Ku263
>> wlvn0HLEH/8xwFl1pRydLhVUk54wHE2ImFRe5IZivGP5L0RUlaov/ihfi1KkJRq5
>> wI4j1d/FJecpQ38G7YdeLHU3R2XNQIh4Oqa8wIOyJVhkLSC4YgwAA5ZkslJ/tQLj
>> yNQBlGJF3j2FHWHsqp6FZWJjXy4kalz5zTatW5DDbdp6k9qT9Tt+RHRwY6nf74X0
>> /M/8921w6UJQzeTy4UrP
>> =3JiX
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150205/4c1b8e70/attachment.bin>

More information about the Ndn-interest mailing list