<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
<div apple-content-edited="true"></div>
<br>
<div>
<div>On Feb 15, 2015, at 10:14 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Dear folks
<div><br>
</div>
<div>During the resolution of #1990, <a href="http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing">
SignedInterestProcessing</a> wiki page recommends stop-and-wait in order to fit the validation procedure.</div>
<div><br>
</div>
<div>Stop-and-wait is easy to implement but is not a good design because it throttles command rate. Sliding window such as that used by TCP is a better solution for Interest ordering.</div>
<div>A sliding window based validation procedure could be: a signed Interest is accepted if its timestamp is greater than (latestTimestamp - windowSize), and it hasn't been accepted previously.</div>
</div>
</blockquote>
<div><br>
</div>
If you always check "it hasn't been accepted previously.", how can an attacker replay it (below)?</div>
<div><br>
</div>
<div>Lan<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>The risk is: an attacker can intercept (and block to transmission of) an earlier command, and replay it later.<br>
</div>
<div>Depending on the nature of the command, this attack may or may not cause harmful effect.</div>
<div>
<ul>
<li>"1. turn on kitchen light" "2. turn on bedroom light": reordering doesn't change final state; if the intention is to turn on both lights without caring the order, it's acceptable<br>
</li><li>"1. set light to red" "2. set light to green": reordering causes an undesirable final state</li></ul>
</div>
<div>I think this risk is acceptable, given the risk is always controllable by the requester:</div>
<div>
<ul>
<li>when order of execution doesn't matter (such as in first example), the requester can send multiple commands together</li><li>when reordering (either by network or by attacker) will cause undesirable effects (such as in second example), the requester can adopt stop-and-wait: don't send the second batch of commands before all commands in the first batch are complete</li></ul>
</div>
<div><br>
</div>
<div>What do others on this mailing list think?</div>
<div><br>
</div>
<div>Yours, Junxiao<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <span dir="ltr">
<<a href="mailto:bzhang@cs.arizona.edu" target="_blank">bzhang@cs.arizona.edu</a>></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">
<div>NDN network doesn’t guarantee in-order delivery; the end consumer, either implemented in app or in library, should handle out-of-order packets. This situation is no different from IP.</div>
<div><br>
</div>
<div>I don’t understand why the love of stop-and-wait. Not only did you mention it in this email, but also on the wiki page as a suggested design. Look, you used stop-and-slow because it’s easy to implement, not because it has better features. The traditional
sliding window that TCP uses can do the same and better, and there are other ways to ensure packet order. Just your app uses stop-and-wait doesn’t mean it’s a good one for others. You should stop making such a recommendation, e.g., remove it from the wiki.</div>
<span class=""><font color="#888888">
<div><br>
</div>
<div>Beichuan</div>
</font></span></div>
</blockquote>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu">Nfd-dev@lists.cs.ucla.edu</a><br>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev<br>
</blockquote>
</div>
<br>
</body>
</html>