[Nfd-dev] Signed Interest processing: alternate to stop-and-wait

[Lan Wang (lanwang)]

On Feb 15, 2015, at 10:14 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Dear folks

During the resolution of #1990, SignedInterestProcessing<http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing> wiki page recommends stop-and-wait in order to fit the validation procedure.

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

If you always check "it hasn't been accepted previously.", how can an attacker replay it (below)?

Lan

The risk is: an attacker can intercept (and block to transmission of) an earlier command, and replay it later.
Depending on the nature of the command, this attack may or may not cause harmful effect.

  *   "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
  *   "1. set light to red" "2. set light to green": reordering causes an undesirable final state

I think this risk is acceptable, given the risk is always controllable by the requester:

  *   when order of execution doesn't matter (such as in first example), the requester can send multiple commands together
  *   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

What do others on this mailing list think?

Yours, Junxiao

On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <bzhang at cs.arizona.edu<mailto:bzhang at cs.arizona.edu>> wrote:
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.

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.

Beichuan
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150217/20429d7f/attachment.html>