[Nfd-dev] LINK spec discussion

[Wentao Shang]

On Sun, Sep 14, 2014 at 2:55 PM, Wentao Shang <wentaoshang at gmail.com> wrote:

> I was involved in the previous discussion and I have a quick question:
>

"was -> wasn't". Sorry about typo :P

Wentao


> 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?
>
> 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?).
>
> Wentao
>
> On Fri, Sep 12, 2014 at 4:40 PM, Alex Afanasyev <
> alexander.afanasyev at ucla.edu> wrote:
>
>> Hi!
>>
>> I want continue our discussion about LINK specification (
>> named-data.net/downloads/memos/link.pdf).
>>
>> Currently we preliminary defined three elements:
>>
>> a) link for redirection:
>>
>>     signA("nameA", content: "nameB")
>>
>> b) link for delegation
>>
>>     signA("nameA", content: signB("nameB", content: "prefixOfNameA"))
>>
>> c) "link" for encapsulation
>>
>>     sha256("nameB" | "nameA", content: ("delegation or redirection link",
>> data("nameA"))
>>
>>
>> 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.
>>
>> 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:
>>
>> - 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
>>
>> - 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.
>>
>> 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?
>>
>> 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.
>>
>> 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.
>>
>>
>> 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).
>>
>>
>> ---
>> Alex
>>
>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>
>
>
> --
> PhD @ IRL, CSD, UCLA
>



-- 
PhD @ IRL, CSD, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140914/58090105/attachment.html>