Feature #1814
closed
Secure localhost data retrieval through NFD
0%
Description
Some localhost applications (such NRD, PIB) may produce data packets.
Consider the high volume of produced data packets, it would be too expensive to sign every data packet.
Therefore, it would be useful to have another mechanism to authenticate data without signature.
One solution to the problem could be relying on NFD forwarding to "authenticate" the data produced by localhost applications.
Specifically, since authentication is required to register /localhost/nrd, NFD can associate the prefix to the face of NRD.
As a result, if we can trust NFD to forward NRD interests only to the face of NRD and trust NFD to reject a data packet with the prefix /localhost/nrd when it is not received from the face of NRD, then we can safely assume that all NRD data are actually produced by NRD, and no authentication is required any more. Same for PIB (/localhost/pib).
With the solution above, localhost applications (such as NRD, PIB) does not have sign their data, and other applications talking to them does not have to verify the data neither.
Updated by Junxiao Shi over 10 years ago
Signing is a bottleneck, as measured in #1589 note-1.
This Feature eliminates the signing overhead of Data packets under ndn:/localhost.
However, the majority of Data packets are intended for remote nodes, so they are not under ndn:/localhost and are not optimized with this Feature.
Task #1204 can reduce signing overhead of all Data packets.
Hopefully that would be a much better solution to reduce the average signing cost.
Updated by Junxiao Shi about 10 years ago
- Start date deleted (
08/01/2014)
20141114 conference call discusses this problem. Consensus:
- Local application SHOULD sign their Data.
- In the general case, NFD SHOULD NOT accept unsolicited Data into ContentStore. Instead, local applications should use InMemoryStorage to maintain their own caches.
Currently, for a Data that matches at least one PIT entry, NFD does not look at out-record, thus does not enforce symmetric path.
This would still allow cache poisoning, but it's a separate issue.
Updated by Junxiao Shi about 10 years ago
- Is duplicate of Feature #2181: Disallow unsolicited Data from local apps added
Updated by Junxiao Shi about 10 years ago
- Status changed from New to Rejected
This proposal itself is rejected because not signing Data is bad practice.
Updated by Junxiao Shi almost 10 years ago
- Is duplicate of deleted (Feature #2181: Disallow unsolicited Data from local apps)