Detection and Mitigation of Cache Poisoning of NDN

Ayush Mattoo, Jyot Saini, Yinuo Feng

Installation Process - Trial and Error

Documentations incorrect at times

Editing for source code, to get the


  • NDNSIM on Mac

NDNSIM can be successfully installed on Mac OS, though we had a lot of struggles in getting it working. Such as when configuring ndnSIM with python visualizer, the program fails to compile. Compilations also take a long time, up to half an hour, so compiling with trial and error took a long time for us to figure out.

When running ./waf command, will fail between 1900-2000 lines due to:

We tried to figure out why this happened, based on past experiences. Someone suggests that using ns-3.25 instead of the latest version may help. But I failed again in the build step.

We also failed of trying CXXFLAGS="-Wall" ./waf configure ./waf -vv, as some people said the failure may be caused by version of gcc and ns not matching.

We also tried XQuartz, but it didn't work.

For compiling and running ndnSIM without python, the process can be finished. But as the program is not running with python, the visualizer cannot be used which makes analysis hard.

We also couldn’t install NDNSIM on a Linux lab computer, we have no permission to run sudo with our account.

Current Steps:

Needless to say, we’ve spent a lot of time since our last update familiarizing ourselves with NDNsim as a group. This has helped us to reassess our next steps and be more realistic with our timeline.


Our current implementation plan is thus quite simple and can be boiled down to 4 steps.

1) We plan to extend the Producer class in NDNsim to create a Poisoner class, which sends poisoned packets intermittently or always (this should be something we can modify).

2) We would also thus extend the data packet class to create a poisoned packet class.

3) We would also be implementing a novel cache flush function.

4) Finally, after these 3 items have been prepared, we can start creating simulations to gauge performance. We may also need to modify the tracers that come with NDNsim to help measure performance, though this is something that we have not looked into too deeply yet.


Our goal is to have a very basic simulation with 3 producers and 1 poisoner in a grid network ready to go by the end of this week, before we can move onto more complex simulations.

Delivering for the final report


In the final report, we will summarize the implementation, findings, and recommendations in lieu of the results from the simulation.


The implementation will talk about:

How we tinkered with the data packet using ndnSIM (the named data networking simulator) and how we managed to manipulate the ndnSIM and its packets using our knowledge of networking. Going in depth into the design decision, we discussed why we thought these changes would have the most impact on the findings we desired to see in the simulation.


Findings will illuminate on:

  1. What distinguishes the authentic simulation from the modified version,

  2. Whether the findings were as expected or unexpected,

  3. Finally, the results in terms of performance compared to what is needed to minimize the problem of cache poisoning.

  4. Comparing our novel solution with solutions available for TCP/IP.


Recommendations for future research

  • If we were able to further our research, what steps would we take in order to improve our solutions.

  • Also, the steps we would take to create a more robust and comprehensive method to diminish cache poisoning.

In conclusion

For this update, we accomplished setting up the simulator, got familiarized with the code and documentation. Using that knowledge, we have come up with concrete steps and some performance metrics we want to test.