[Ndn-interest] Repo-ng freshness period

[Marc.Mosko at parc.com]

Matteo,

If you expect to put a FreshnessSeconds in a certificate Data object that corresponds to the certificate’s validity period, I do not think you will get the behavior you want from NDN.  The FreshnessPeriod is the relative time (in seconds) from when a ContentStore receives a Data Object to when it will consider it stale.  This process is repeated at each hop.

If you are putting a 10 second FreshnessSeconds in a certificate Data object to force nodes to “phone home” to the repo every 10 seconds, you will not always get that either, because the 10 seconds is reset at each hop.  Each hop along A -> B -> C -> … fetches the certificate after 9 seconds, it will always be considered fresh for every hop and could thus live as fresh in the network for a long time.

Usually getting the most recent data object is controlled by using a version (timestamp or sequence number) in the Data object’s name, then using selectors to get the right-most child (which due to caching may need to be repeated).

Here’s an example:

As an example, let’s assume it’s January 1 at 00:00:00 and your certificate expires at January 11 00:00:00 (864,000 seconds).  So, node A publishes the certificate with a FreshnessSeconds of 864,000.  It is then retrieved as follows:

A -> 1 hour -> B -> 5 days -> C

Node B will receive the certificate at January 1 01:00:00 (3600 seconds), so node B will consider it fresh until 864,000 + 3,600 = 867,600 seconds (January 11 01:00:00).

Node C will receive the certificate after a delay of 3,600 + 432,000 = 435,600 seconds, so node C will consider it fresh until 1,299,600 seconds after node A published it (January 15 01:00:00).

You could take a look at what NDN did in one of the recent NDNfit security papers, where they encoded the validity periods as part of the key’s name (I don’t remember the paper title right now), but it was something like NDN for constrained environments.

Marc



On Dec 12, 2016, at 2:53 PM, Matteo Bertolino <Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>> wrote:

Dear Junxiao,
I understand (finally) what you mean.
Since I generate the certificates with ndnsec, is there a method to obtain that?

Thanks a lot,
Bests, Matteo

Quoting Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>:

Hi Matteo

You should change the program that generates and signs the certificate to
add FreshnessPeriod, not repo-ng.
If you patch repo-ng to update the certificate, it would not be valid
anymore because the FreshnessPeriod is protected by the signature.

Yours, Junxiao

On Mon, Dec 12, 2016 at 3:27 PM, Matteo Bertolino <
Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>> wrote:

Supposing that I would like to use repo-ng to store and to distribute the
certificates. I can publish a certificate, for example, writing:
base64 -d cert.ndncert | nc localhost 7376 in the very basic case.

Now, client express an interest in order to retrieve cert.ndncert.
I imagine, seeing the code, that repo-ng take the data and put the data in
the face in order to satisfy the interest. Exactly like any other
application.
I would like to avoid that another node , that desire FRESH content,
retrieve that certificate after 10 seconds on an intermediate cache. The
request should arrive to repo-ng, instead of intermediate node.

The solution you proposed is not enough for this purpose. Are you sure
that I cannot obtain this behaviour? It seems quite strange, probably I
don't explained very well what I wish.





-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr<http://webmail.eurecom.fr/>


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161213/cb53d492/attachment-0001.html>