<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 15, 2014 at 10:11 PM, Yingdi Yu <span dir="ltr"><<a href="mailto:yingdi@cs.ucla.edu" target="_blank">yingdi@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><span style="text-align:-webkit-auto">On Sep 15, 2014, at 9:54 PM, Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>> wrote:</span><br><div><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Mon, Sep 15, 2014 at 9:19 PM, Yingdi Yu<span> </span><span dir="ltr"><<a href="mailto:yingdi@cs.ucla.edu" target="_blank">yingdi@cs.ucla.edu</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">On Sep 15, 2014, at 5:20 PM, Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>> wrote:</div></span></span></div></span><div><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Sep 15, 2014 at 4:02 PM, Alex Afanasyev<span> </span><span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span><span> </span>wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><span><br>On Sep 15, 2014, at 3:50 PM, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu" target="_blank">lixia@cs.ucla.edu</a>> wrote:<br><br></span><span>> 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></span><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. </span></blockquote><span><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.</div></span></div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>In this case, yes, double signature is not necessary because the link is pointing to the client's own data. As I said, double signature is only meaningful when the link tries to connect two different parties.</div></div></blockquote><br></div></span><div>then what is the gain of the second signature in the second case? For those who just want to send the interests, they do not care whether the second signature exists or not. For the provider, they can simply discard the interests for the data that the provider does not host.</div></div></blockquote><div><br></div><div>At least this avoids providing *new* methods for DDoS attack. But, again, I don't disagree that such kind of attacks may not be practical in real life (as we see now) and it's not worth it to add such complexity at network packet level.</div><div><br></div><div>BTW: given that I didn't participate in the early discussions, I'm curious how this "delegation object" was proposed in the first place and what the original purpose is. I'd like to check whether my understanding is consistent with the original author's.</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 style="word-wrap:break-word"><div><br></div><div>I just do no think the second signature can mitigate the DDoS attack, but I do agree with Lixia that the second signature might be useful if some data consumers or intermediate routers want to know whether the data is indeed from the requested provider. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Yingdi</div><br></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">PhD @ IRL, CSD, UCLA</div>
</div></div>