<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 15, 2014 at 4:02 PM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Sep 15, 2014, at 3:50 PM, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>> wrote:<br>
<br>
><br>
> On Sep 15, 2014, at 1:09 PM, Alex Afanasyev <<a href="mailto:alexander.afanasyev@ucla.edu">alexander.afanasyev@ucla.edu</a>> wrote:<br>
><br>
>> On Sep 15, 2014, at 12:54 PM, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>> wrote:<br>
>><br>
>>> top posting: sorry I'm falling behind email; Yingdi reminded me today that there is an exchange going on here.<br>
>>><br>
>>> maybe I read the long msg too quick: I got confused with whether nameA=ndnSIM, or nameA=att in Alex's argument ....<br>
>>><br>
>>> I also do not understand the format of (b) below...<br>
>>><br>
>>> Further, what is "link for encapsulation"...  My understanding says that an encapsulated Data packet includes 2 objects, a LINK and a Data, so what is "link for encapsulation" ?<br>
>><br>
>> Please see the <a href="http://named-data.net/downloads/memos/link.pdf" target="_blank">named-data.net/downloads/memos/link.pdf</a> spec.  I intentionally did not fully described all the option and listed just a summary of what we currently have in the link.pdf.  All naming is very preliminary, so it could be confusing.<br>
>><br>
>> ---<br>
>> Alex<br>
><br>
> still have not read the spec yet but did caught up all the msgs. Here is a summary of my summary/opinion:<br>
><br>
> 1/ I agree with Wentao on the following:<br>
><br>
>> a link object "A -> B" involves two parties, i.e., A and B. Unless A and B are actually the same party, you need to have two signatures, one from A and one from B, to indicate that both parties have agreed on this link relationship.<br>
<br>
</span>This is very general statement.  On a surface, this could be a desired property.  The whole question which goal is this property achieving?  In my opinion, giving provider a tool to allow/deny hosting things inside the provider is much bigger harm then allowing anybody to express their desire for their client to try to request data from the specific provider.  </blockquote><div><br></div><div>I don't quite understand this argument: if the provider doesn't want to host the client's content, the link relationship wouldn't have existed in the first place. The signature is only a technical means for the provider to express its approval of hosting. Whether the provide *will* host or not sounds more like a layer-10 issue to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I mentioned before, even if such property implemented in the LINK, how is it different from just sending of bunch of unsatisfiable Interests towards the provider?<br></blockquote><div><br></div><div>I'm not comfortable with the logic behind this argument: if there are two backdoors that can lead to the same security hole, can we simply say that we can leave the 2nd door open because the hackers are going to use the 1st door anyway?</div><div><br></div><div>I think the key issue here is really the cost of having such complexity versus how much we can gain from it. For that I don't have a good answer. Current Web architecture has been running with uni-directional links for years without (??) major problems. So I feel we can use "redirect LINK object" as the default and keep the "delegation LINK object" as optional for the applications to choose.</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">
<span class=""><br>
<br>
> I disagree with Junxiao's comment that<br>
><br>
>> A drawback of delegation record is: it promotes content control by ISP.<br>
>> In IP DNS, user has the freedom to host any website on the IP address (unless ISP deploys layer-7 filtering).<br>
>> If a delegation record is needed, ISP could refuse to sign a delegation record if they don't want user to host a certain website.<br>
><br>
> the ISP only signs the delegation of /att/lixia, not /lixia/foobar (the content name) that I may publish.<br>
<br>
</span>I disagree, since this is not a fair example: it does not show all the "danger".  You assume here that you "own" just /lixia namespace and you publish data only under this namespace, which somehow is related to your relationship with att.<br>
<br>
In more general, I could own/control a bunch of namespaces, which has nothing to do with me as ATT customer.  Let's say we have /att (routable) and /net/ndnsim, /net/6watch, /net/named-data (all unroutable, but somewhere inside att network).<br>
<br>
ATT would need to sign all these delegations, essentially having "control" over which namespace can be served by ATT network and which not.<br>
<span class=""><br>
><br>
> 2/ I agree with Yingdi that it's desirable to have some simple concatenation rule to glue together the routable-prefix and non-routable name for encapsulated Data packet, a much better way to go than any partial rewrite/replacement of the name.<br>
><br>
> 3/ The LINK object in an encapsulated Data packet should be signed, this enables whoever interested in checking the authentication of the LINK to do so (yes there is still the trust model question to answer, but without this signature, one cannot check).<br>
<br>
</span>This one needs to be more specific.  Which option you're talking about here?  We have 3 "link objects" (we need to have a better terminology for that), each having different set of security parameters and meanings.<br>
<br>
---<br>
Alex<br>
<div class="HOEnZb"><div class="h5"><br>
> 4/ there is one detail I'd like to spell out explicitly: my understanding is that all the unroutable names that publish globally reachable contents should be globally unique, they are just not on the global routing table.<br>
><br>
> 5/ to answer JeffB's question: I think the assumption here is only that a resolution system can be used to get the routable prefix for an unroutable name; NDNS can be a candidate here.  No decision has been made anywhere at this time.<br>
> We need a NDNS TR out ASAP, then an NDN seminar on the topic, as one of the next steps.<br>
><br>
> my 2 cents,<br>
> Lixia<br>
><br>
><br>
<br>
<br>
_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu">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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">PhD @ IRL, CSD, UCLA</div>
</div></div>