[Ndn-interest] Repo-ng freshness period

Matteo Bertolino Matteo.Bertolino at eurecom.fr
Tue Dec 13 01:16:19 PST 2016


Dear Marc,
thank you your explanation, it is really clear and you convinced me  
that I cannot get the desired behavior just from NDN.
About this case I really convinced, however I need to renew the  
question, because repo-ng could be used for the storage of different  
file.

The one of the certificate was only an example, but at the end how can  
I avoid that intermediate content store consider the data  published  
by repo-ng fresh indefinitely?

Quoting 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
>
>



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




More information about the Ndn-interest mailing list