<div dir="ltr"><div><div><div><div>Hi,<br><br></div>Thanks for the help, Lixia and Kundan. They helped clarify a lot of things for me. I however got a few more doubts going through the resources.<br><br></div>1) Suppose a Mal-User floods the PIT with requests for packets that don't exist, how does the Router prevent itself from being overpopulated with bad Requests and continue to serve genuine Requests?<br><br></div><div>2) Regarding the Certificate Revocation framework, is there an existing methodology to know if the producer has been compromised?<br></div><div><br></div>3) I was also hoping for a few resources on How the FIB is populated.<br><br></div><div>Thanking you in advance and hoping for your guidance.</div><div><br></div><div>Yours sincerely,</div><div>~Shashank G<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 25, 2023 at 10:56 PM Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"CertRevoke: A Certificate Revocation Framework for Named Data NetworkingShashank, thanks for exploring NDN! From your questions, I guess you may be looking into NDN's name-based access control (NAC) solutions?<br>
<br>
Your first question: the concern seems that, given the data decryption key is encrypted in an object X using a legit's user Y's public key, an attacker Z could easily fetch the decryption key. As Kundan explained, Z can get a copy of X, but wont be able to read the decryption key in it, because Z doesn't have Y's private key.<br>
<br>
Your 2nd question: a good question, yes it is possible to compromise a producer and its key needs to be revoked. NDN based systems try to minimize the danger and damage of key/cert compromises by shortening their life times, though compromises detection is still needed.<br>
for revocation, there's initial work on NDN cert revocation: "CertRevoke: A Certificate Revocation Framework for Named Data Networking", <a href="https://dl.acm.org/doi/pdf/10.1145/3517212.3558079" rel="noreferrer" target="_blank">https://dl.acm.org/doi/pdf/10.1145/3517212.3558079</a>, which utilizes distributed ledgers. The paper referenced DLedger from several years ago, a more recent work is<br>
"CLedger: A Secure Distributed Certificate Ledger via Named Data"<br>
<a href="https://ieeexplore.ieee.org/document/10279244" rel="noreferrer" target="_blank">https://ieeexplore.ieee.org/document/10279244</a><br>
again this is very initial work, we are extending it in another ongoing project to cover more general cases.<br>
<br>
Lixia<br>
<br>
> On Dec 24, 2023, at 11:02 PM, Shashank G via Ndn-interest <<a href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank">ndn-interest@lists.cs.ucla.edu</a>> wrote:<br>
> <br>
> Hi all,<br>
> <br>
> I am Shashank, a sophomore at National Institute of Technology, Karnataka from India. I recently began exploring NDN and have been fascinated by its data security aspect. However, since I am new to the field, I have quite a few doubts regarding the same, and I was hoping for your patience and guidance to clarify them.<br>
> <br>
> 1) I was trying to understand how cryptographically signing packets works, and have got a certain grasp of it's advantages, however, I had a doubt - If the public keys themselves are named, then with the right naming convention, couldn't an attacker get access to data that he is not supposed to view. How is this prevented?<br>
> <br>
> 2) Is there any mechanism to detect if the producer of data has been compromised, i.e, his private key has been obtained by a third party? If so, since the certificates are cached, how do we detect if the producer is safe or not?<br>
> <br>
> I look forward to learning a lot here and eagerly await your response. Thank you.<br>
> <br>
> Yours sincerely,<br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
<br>
</blockquote></div>