2016.09.06 - Reading session 1: ICN'16

• Participants: Haoyuan Xu, Jiachen Chen, Sugang Li, Wuyang Zhang, Ying Liu, Zhenhua Jia
  
• Summary: We managed to finish 2 papers in this meeting. We also went through some basic discussions on NDN & congestion control.

Papers

ID	Paper	Presenter	Slides
1	Sharing mHealth Data via Named Data Networking	Sugang
2	Network Names in Content-Centric Networking	Wuyang

Reviews

ID	Jiachen	Haoyuan	Sugang	Zhenhua	Ying
1	Review
2	Review

Discussion Notes

• Named-Data Networking, Content-Centric Networking
  1. Components in a forwarding engine (FIB, PIT, Content Store)
  2. Forwarding rule
• Basic knowledge about congestion control
  1. Why window-based, how does it look like
  2. Why hop-by-hop fairness does not work (dumbell topology with 2 bottlenecks)
  3. Controlling window is not equal to controlling rate
  4. Buffer bloat and active queue management (RED/CoDel)
  5. Fast recovery and why it is not feasible in NDN
• Network Names in Content-Centric Networking
  1. This paper is not well written. Problems:
     • It did not cover the security issue mentioned in the abstract.
     • The evaluation did not compare the proposed solutions with other solutions.
     • The packet header is still with variable length in the design.
  2. However, there are also something interesting in the paper:
     • This solution enables hash, at the same time allows for longest prefix matching.
     • From the hardware design point of view, it is simpler than trie (tree), and it has comparable lookup efficiency.

• Sharing mHealth Data via Named Data Networking
  1. Problems with the paper:
     • ICN is not quite beneficial according to the solution
     • The paper assumes DSU and DPU are benign.
     • The key exchange model in sec. 2.5 is not clear. Should read the NAC citation [11] in the paper for further information. However, this should not be counted as novelty of the paper.
  2. Interesting topics in the paper:
     • The solution can benefit IP-based solutions -- we can also sign the contents in IP, rather than only securing the channels.
  3. Key exchange procedure in the paper
     1. Data generator (Fitbit) generates a data and uses a symmetric key (C-KEY) to encrypt the content.
     2. Data generator gets a key-encrypt key (KEK) from the data owner (me) and encrypts the C-KEY with KEK.
     3. Data consumer (DPU/DVU) gets a key-decrypt key (KDK) from the data owner, and get an encrypted C-KEY (by KEK), and an encrypted data (by C-KEY) from the data generator.
     4. Data consumer gets C-KEY using KDK and gets data using C-KEY.
     • Problem: the data owner now reveals both KEK and KDK (a key pair) to the network. How to prevent the leak of KEK/KDK?
     • One interesting thing: there should be no pre-known mapping between data generator and consumer. A data generated now might be used by some future DPUs/DVUs.

• Basic of cryptography
  • Assumption: U_a has a private key a, U_b has private key b.
  • Todo: U_a and U_b should have a symmetric key, but U_a should not know b, nor should U_b know a. Evesdropper should know neither a nor b.
  • Prerequirement: there are two well-known integers q and g.
  • Process:
    1. U_a sends A = q ^ a % g to U_b
    2. U_b sends B = q ^ b % g to U_a
    3. U_a uses B ^ a % g as the key
    4. U_b uses A ^ b % g as the key
  • Proof of symmetric:
    A ^ b % g = (q ^ a % g) ^ b % g
    Let q ^ a = n * g + v_a (v_a = q ^ a % g)
    We can get:
    (q ^ a - n * g) ^ b % g = (q ^ (ab) + ? * g + ? * g ^ 2 + ... + ? * g ^ b) % g
(q ^ a - n * g) ^ b % g = (q ^ (ab)) % g
    Similarly, we can get B ^ a % g = (q ^ (ab)) % g
    Therefore, B ^ a % g == A ^ b % g (symmetric).
  • With proper q value, we cannot get x from q ^ x % g. Therefore U_a will not know b, nor will U_b know a, or evesdropper know a or b.