<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 14, 2014 at 2:55 PM, Wentao Shang <span dir="ltr"><<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I was involved in the previous discussion and I have a quick question: </div></blockquote><div><br></div><div>"was -> wasn't". Sorry about typo :P</div><div><br></div><div>Wentao</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">the document says the LINK type will be a "sub-type of NDN DATA packet". Is the "sub-type" referring to implementation mechanism (i.e., Link class is inherited from Data class) or do we actually have some way to encode the "sub-type" relationship in the TLV format?<div><br></div><div>I remember the type field is using flat number so not sure whether the latter is possible. If it is the former case, I don't think specifying implementation detail in the document is a good idea (what if the programming language doesn't support inheritance?).</div><div><br></div><div>Wentao</div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Sep 12, 2014 at 4:40 PM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I want continue our discussion about LINK specification (<a href="http://named-data.net/downloads/memos/link.pdf" target="_blank">named-data.net/downloads/memos/link.pdf</a>).<br>
<br>
Currently we preliminary defined three elements:<br>
<br>
a) link for redirection:<br>
<br>
signA("nameA", content: "nameB")<br>
<br>
b) link for delegation<br>
<br>
signA("nameA", content: signB("nameB", content: "prefixOfNameA"))<br>
<br>
c) "link" for encapsulation<br>
<br>
sha256("nameB" | "nameA", content: ("delegation or redirection link", data("nameA"))<br>
<br>
<br>
The option (b) is the latest addition and I have some reservations about it. In particular, what exactly this delegation achieves? What security problem we are solving with it.<br>
<br>
Let me give some example of (b). I own a "non-routable" namespace /ndnsim and my site is connected to /att and /ucla networks. So, the (b) option would require:<br>
<br>
- I will have to obtain a "redirection" links from /att and /ucla to /ndnsim (option (a)) = get a permission from /att and /ucla to host /ndnsim site<br>
<br>
- Then I will create a delegation packet(s) that I can put in NDNS to tell others that my site is currently available through /att and /ucla.<br>
<br>
The process looks ok, but the question I have is what significance is in the first permission. What is the point of me of requesting permission from my provider to host a website? What I would gain and what provider itself would gain?<br>
<br>
I personally, do not yet see a clear benefit from this process, only that it would complicate the delegation process. Only me is able to tell others that my site is available at different places, so there is no question about others claiming that my site is available somewhere else. If I mistakenly put a wrong link, then I myself will be at loss: i wouldn't be able to serve my content and somebody else would receive my interests and could reply to them with some junk.<br>
<br>
If I "maliciously" put somebody else's network as a link, then interests for my data would go there. But what is the harm? If nobody replies to them, then routers can start ignoring/pushing back such interests. If somebody replying, then somebody serves data and from the network point of view nothing bad is happening.<br>
<br>
<br>
In short, I want us have a deep discussion on what exactly we are protecting and from whom. For me, even with only one signature (option a), only the owner of the original namespace (/ndnsim) is able to create a legitimate link to somewhere else. Additional signature could protect "provider" (destination of the link), but is it really a problem? Anybody could send any number of interests to that provider even without any link (erroneous or malicious).<br>
<br>
<br>
---<br>
Alex<br>
<br>
<br>
<br>
_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">PhD @ IRL, CSD, UCLA</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">PhD @ IRL, CSD, UCLA</div>
</div></div>