[Nfd-dev] NFD breaking change: default unsolicited Data policy

[Junxiao Shi]

Dear folks

I'm changing NFD's default unsolicited Data policy to "drop-all", so that
any unsolicited Data will not be admitted into the ContentStore.
The rationale of this change has been explained by Yingdi in the message
quoted below.
If you need to revert to the previous behavior that unsolicited Data from
local applications are accepted, in NFD config file change
tables.cs_unsolicited_policy option to "admit-local".

This change will merge no earlier than Sep 03.
You can try your projects with NFD Change https://gerrit.named-data.net/3143
and verify it works.

Yours, Junxiao

On Sun, Sep 7, 2014 at 9:41 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:

> Hi all,
>
> Beichuan and I had a discussion about a backdoor of nfd which allows apps
> to dump unsolicited data packets into content store of local nfd and how to
> close the backdoor. Here is a summary of the discussion, we would like to
> hear your comments. If people agree with it, we will start the
> implementation soon.
>
> ================
> 1. NFD backdoor
> Current NFD implementation allows local applications to dump unsolicited
> data packets into content store. This backdoor enables malware to cache
> poison local content store. To close the backdoor, nfd should 1) reject
> unsolicited data packets and 2) authenticate prefix registration on local
> nfd.
>
> 2. In-app storage
> Some existing applications (such as ChronoChat) are using the backdoor to
> abuse local content store as an in-memory storage of data packets, because
> current library does not provide in-app storage. The differences between
> content store and in-app storage include:
> a) content store is a cache, it is not guaranteed that a data packet will
> always be there. In contrast, the existence of a data packet in an in-app
> storage is completely under the app's control.
> b) content store is aware of FreshnessPeriod of data packets, but an
> in-app storage should not.
>
> The working flow of in-app storage is: an app creates its own in-app
> storage. If the app generates some unsolicited data packets and insert them
> in the in-app storage. When receiving an interest, the app will first try
> to see if there is a matched data packet in the in-app storage and then
> process the interest if there is no matched data. With the in-app storage,
> apps do not need to abuse content store, and we can eliminate the source of
> unsolicited data in the localhost environment.
>
> For now, we need to provide two types of in-app storage:
> a) explicit-controlled storage: data packets need to be explicitly
> deleted; when storage is full, all data insertions must fail until app
> explicitly increases the capacity of the storage.
> b) FIFO: capacity is fixed, the first inserted data will be automatically
> deleted when the storage is full.
> The implementation of the in-app storage could be more flexible to support
> other strategies, but the two above seems to be sufficient for now.
>
> 3. Authentication of prefix registration on local nfd
> Currently all apps are using the system-default key to sign prefix
> registration command. There are several drawbacks of this mechanism:
> a) every app get the access to the system-default private key.
> b) the system-default key is trusted to register any prefix.
>
> A better model should be: users should have per-prefix registration keys
> (the privilege of the key is expressed in the key name), and authorize
> applications to get the access of key for particular prefixes. This
> resembles the network control model of current os, e.g., when a user starts
> a new app which will listen to some ports, the os will ask user to give the
> permission to the app.
>
> More specifically, when an app wants to register a prefix "/a/b", it will
> first look for a key "/localhost/prefix-register-key/a/b/[keyId]" in the
> user's keystore. If there is no such key, the app will create one and ask
> for user's permission. User authorizes that by signing the
> prefix-register-key using user's own key (whose privilege is pre-configured
> at nfd side). After that the app will use key "/localhost/prefix-register-key/a/b/[keyId]"
> to sign request for prefix "/a/b". At the nfd side, nfd will check:
> a) whether the requested prefix matches the signing key name.
> b) whether the key "/localhost/prefix-register-key/a/b/[keyId]" is signed
> by a trusted user.
> c) whether the user is allowed to register the prefix.
> The request will be accepted only if all the three conditions are
> satisfied.
>
> If an app finds that the prefix-register-key it needs has already existed
> in the user's keystore (e.g., created by some other apps), it will ask the
> user for the access to the existing key. This access control feature is
> already supported by the osx-keychain based keystore.
>
> ================
>
>
> Yingdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160829/78bfb6e5/attachment.html>