Why Named Data Networking(NDN)?
Before we jump into jargons, let’s ask ourselves a simple question: How do you Google? (For Chinese users, unfortunately, you don’t Google at all… Then how do you Bing?) You type in Google.com, and the browser magically jumps out the page. But is that all? The truth is, in current protocol TCP/IP, every Internet packet needs a source and a destination. You may think this is trivial; you do that every day when you mail a UPS. But src and dest address is not trivial in Networks when the address is composed of 32 bits. The solution? DNS server. You merely ask this server: Where are Google and you get the answer. Then what is the source? We used to configure it manually, but now we have DHCP to take care of that.
You can easily see the security problems behind this. Is DHCP safe? Can it be possible that someone pretends to be your router and gave you a fake address and reads all your communication? Is DNS safe? Can someone give you the wrong one and lead you to Baidu.com instead of Google.com? Well if you are a China Telecom’s user, you run into this on a monthly basis because they hijack your DNS server to insert their ad. And is your communication safe? Till now we still have web pages communicate with HTTP where all the data is not encrypted, meaning everyone can read it.
But do you care about that? No, all you need is data. The simple search results from Google. Then why bother with connection since TCP/IP is connection based? What we need is a network architecture that is data based. And that’s when you need NDN.
Introduction to NDN
NDN is a new networking architecture putting data as first priority passenger. Unlike TCP/IP, there is no address in this architecture. In NDN, every piece of data is named. To fetch a data, the consumer may merely express an Interest packet with the name of that data and specific parameters. Data packet, on the other hand, starts with the name of the data, followed by the data and the producers signature. Every entity in NDN must have an identity and that entity can generate signatures. Thus the signatures allow all the consumer to verify that the data is secured and unchanged.
For each and every router in this network, the following protocol has to be performed to guarantee the delivery of the packets.
OpenmHealth & NDNFit
OpenmHealth is a set of applications that initially proposed to do health data tracking. It consists of several units including Data Storage Unit(DSU), Data Processing Unit(DPU), Data Visualization Unit(DVU) and most importantly, Data Capture, which is most likely to be your cell phone.
Our concern is that it runs over TCP/IP, causing large overhead when sharing data. This overhead cannot overcome since whenever transferring to a new destination, the network has to retransmit the data since the packet changed(even though the data remains unchanged). It is also worth mentioning that this is quite a problem in nowadays network architecture and it’s more problematic if the scope changed from data sharing to (torrent) downloading, video streaming, gaming, etc. These scenarios generally have more participants, and the overhead can grow linearly as the user increases.
However, using NDN may solve duplicated transferring overhead, it’s no panacea. The presence of NDN introduced other problems. One of them involves data producer. How can a server know that the health data it received are generated by the user’s cell instead of some malicious attacker? Also, how can a server reply Interests when it has no idea who sent it? Indeed, no one wants to share personal data with an untrusted person. Then how do we enforce that?
This is when we introduce Identity Manager, which manages all the identity in the network and allows identity verification for all entities in NDN.
IdentityManager
Every entity in the network needs an identity. It can be a self-generated one or one issued by a commonly trusted server. In our approach, we would ask the Certificate Authority(CA) for a user certificate. The user can then use that certificate to generate application certificates and issue to his(her) applications. These applications, in turn, will use the certificate to sign all the packets it sends. Other entities in this network can then verify the identity of the packet.
Whenever there is a new Application, the following logic check should be performed.
The problem proposed above can be solved. The attacker can never send a valid Interest since he cannot get the identity to sign the packets. Whatever he replies to the Interest will be ignored. He cannot access personal data too for the same reason. With no valid identity, his Interest will never be replied.
NDNCERT
The problem arises when we have to ask, how to get a user certificate. CA can issue one, but there is no safe way to deliver it over the Internet. This is a chicken and egg problem. How do you deliver a certificate used to guarantee safety when there is no safety? Our solution is NDNCERT, which is a protocol that can safely get the certificate. The protocol can be seen below.
certificate requester CA
| _PROBE |
| --------------------------------> |
| |
| Get the available namespace
| Data |
| <-------------------------------- |
| |
Generate key pair |
Generate certificate request |
| |
| _NEW |
| --------------------------------> |
| |
| Generate available challenge list
| Store request instance
| and Generate request ID
| Data |
| <-------------------------------- |
| |
select challenge |
| _SELECT |
| --------------------------------> |
| |
| Prepare the challenge for requester
| Data |
| <-------------------------------- |
| |
Perform Challenge |
| _VALIDATE |
| --------------------------------> |
| |
| Check the challenge result ..+
| | .
| | V
| | Verify result
| | .
| | V
| | If valid,
| Data | publish certificate
| <-------------------------------- |<.... If not finished,
| | generate status code
| | If invalid,
| | generate error code
...
Certificate requester sends one or more _VALIDATE to finish challenge.
Certificate requester can periodically send _STATUS to check status
until the cert is issued
...
| |
| _DOWNLOAD |
| --------------------------------> |
| Data |
| <-------------------------------- |
Android
Finally, this tool has to run on cell phones. Because of most applications, including our data capturing one, runs on cell phones. However, why not Apple? We ruled in favor of Android because we think in the long term Android can be rooted to support pure NDN(currently, it runs over IP), which is not possible for Apple.
However, Android is Java-based, yet our protocol and libraries are written in C++14. We considered both the possibility of using Java Native Interface(JNI) and rewrite NDNCERT using Java(There is Jndn already). We made both and Java-Ndncert approach seems to be more successful. Our re-written library is thus called JNdncert. You can check our application here with different branches working on the different approach.
Future
This application is not finished yet. Now we can retrieve a user identity whenever the user requests it. However, we cannot issue application identities yet. We haven’t decided what should each application do to invoke our application. It should be done with an Intent introduced in Android whose philosophy is close to Interest. But we haven’t dug into it.
Finally, Identity Manager should not be only used for NDNFit; it can be the manager for whatever application in the future as long as data should be protected per user.