[Nfd-dev] Signed Interest processing: alternate to stop-and-wait
yingdi at CS.UCLA.EDU
Tue Feb 17 13:05:29 PST 2015
I do not like the idea of handling timestamp and nonce in the validator. The validator checks signatures. The timestamp and nonce is not the attributes of signatures but the attribute of the command. So timestamp and nonce should be handled by those which process the command.
Actually, there are a variety of mechanisms to check timestamps. If we move the timestamp and nonce checking out of validator, then applications can freely choose the timestamp checking mechanism that fits their requirement best. Say if stop-and-wait fits the requirements of an app, then there is no need to use or implement sliding window. If strong sequencing is required, the app may use the timestamp as a session id and append sequence number after the timestamp, and then the nonce. For commands in the same session, they can be issued without waiting for the ack from the other side.
I just do not feel it correct if we hardcode the timestamp checking procedure as a part of signature verification, because it forces every application to use the same timestamp checking mechanism. This is my 2 cents.
> On Feb 15, 2015, at 8:14 PM, Junxiao Shi <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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nfd-dev