[Nfd-dev] LINK spec discussion

[Yingdi Yu]

On Sep 15, 2014, at 5:20 PM, Wentao Shang <wentaoshang at gmail.com> wrote:

> 
> 
> On Mon, Sep 15, 2014 at 4:02 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> 
> On Sep 15, 2014, at 3:50 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
> 
> > 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. 
> 
> 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.

No, it is not about hosting the client's content, the client still hosts its own data from its own machine, but the machine is connected to the internet through att's network. Basically, the client only bought the internet access from att. If a link object signed by att is required to publish the data, it implies that att can decide the type of data that the client can publish. I think this violates the network neutrality, and nobody would like that.

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

No, the logic is: if one of the backdoor is easier to be exploited to launch an attack, what is the point of fixing the other backdoor (which is more difficult to be exploited)? Attackers are not fools.

Yingdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140915/f5caaec8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140915/f5caaec8/attachment.bin>