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

[Junxiao Shi]

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.

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>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150215/2dd62c4d/attachment.html>