[Nfd-dev] LINK spec discussion

[Alex Afanasyev]

On Sep 15, 2014, at 3:50 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:

> 
> On Sep 15, 2014, at 1:09 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> 
>> On Sep 15, 2014, at 12:54 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
>> 
>>> top posting: sorry I'm falling behind email; Yingdi reminded me today that there is an exchange going on here.
>>> 
>>> maybe I read the long msg too quick: I got confused with whether nameA=ndnSIM, or nameA=att in Alex's argument ....
>>> 
>>> I also do not understand the format of (b) below...
>>> 
>>> 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" ?
>> 
>> Please see the named-data.net/downloads/memos/link.pdf 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.
>> 
>> ---
>> Alex
> 
> still have not read the spec yet but did caught up all the msgs. Here is a summary of my summary/opinion:
> 
> 1/ I agree with Wentao on the following:
> 
>> 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.

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.  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?


> I disagree with Junxiao's comment that
> 
>> A drawback of delegation record is: it promotes content control by ISP.
>> In IP DNS, user has the freedom to host any website on the IP address (unless ISP deploys layer-7 filtering).
>> 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.
> 
> the ISP only signs the delegation of /att/lixia, not /lixia/foobar (the content name) that I may publish.

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.

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).

ATT would need to sign all these delegations, essentially having "control" over which namespace can be served by ATT network and which not.

> 
> 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.
> 
> 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).

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.

---
Alex

> 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.
> 
> 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.
> We need a NDNS TR out ASAP, then an NDN seminar on the topic, as one of the next steps.
> 
> my 2 cents,
> Lixia
> 
>