<div dir="ltr"><div>Dear folks</div><div><br></div><div>I'm changing NFD's default unsolicited Data policy to "drop-all", so that any unsolicited Data will not be admitted into the ContentStore.</div><div>The rationale of this change has been explained by Yingdi in the message quoted below.</div><div>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".</div><div><br></div><div>This change will merge no earlier than Sep 03.</div><div>You can try your projects with NFD Change <a href="https://gerrit.named-data.net/3143">https://gerrit.named-data.net/3143</a> and verify it works.</div><div><br></div><div>Yours, Junxiao<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 7, 2014 at 9:41 PM, Yingdi Yu <span dir="ltr"><<a href="mailto:yingdi@cs.ucla.edu" target="_blank">yingdi@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Hi all,</div><div><br></div><div>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.</div><div><br></div><div>================</div><div><div>1. NFD backdoor</div><div>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.</div><div><br></div><div>2. In-app storage</div><div>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: </div><div>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.</div><div>b) content store is aware of FreshnessPeriod of data packets, but an in-app storage should not. </div><div><br></div><div>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.</div><div><br></div><div>For now, we need to provide two types of in-app storage:</div><div>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.</div><div>b) FIFO: capacity is fixed, the first inserted data will be automatically deleted when the storage is full.</div><div>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.</div><div><br></div><div>3. Authentication of prefix registration on local nfd</div><div>Currently all apps are using the system-default key to sign prefix registration command. There are several drawbacks of this mechanism:</div><div>a) every app get the access to the system-default private key.</div><div>b) the system-default key is trusted to register any prefix.</div><div><br></div><div>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.</div><div><br></div><div>More specifically, when an app wants to register a prefix "/a/b", it will first look for a key "/localhost/prefix-register-<wbr>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-<wbr>key/a/b/[keyId]" to sign request for prefix "/a/b". At the nfd side, nfd will check:</div><div>a) whether the requested prefix matches the signing key name.</div><div>b) whether the key "/localhost/prefix-register-<wbr>key/a/b/[keyId]" is signed by a trusted user.</div><div>c) whether the user is allowed to register the prefix.</div><div>The request will be accepted only if all the three conditions are satisfied. </div><div><br></div><div>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.</div></div><div><br></div><div>================</div><span class=""><font color="#888888"><div><br></div><div><br></div><div>
<span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word"><div>Yingdi</div><div><br></div></div></span></span></div></font></span></div></blockquote></div></div></div>