[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