[Nfd-dev] Signed Interest processing: alternate to stop-and-wait
shijunxiao at email.arizona.edu
Sun Feb 15 20:14:49 PST 2015
During the resolution of #1990, SignedInterestProcessing
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
- "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
- 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?
On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <bzhang at cs.arizona.edu>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nfd-dev