[Nfd-dev] Signed Interest processing: alternate to stop-and-wait
jburke at remap.UCLA.EDU
Tue Feb 17 22:19:33 PST 2015
I thought one design motivation for the security libraries was to implement some widely-applicable techniques so as to avoid likely security screw-ups in applications? Is that something to consider here?
Also, is it practical that the average application would to have to implement timestamp/nonce checking itself to just handle a signed interest? Even if it's not that hard, this seems way too detailed—and unrelated to the actual functionality of many applications—for many straightforward apps that might still use Signed Interests.
A possibility would be to offer one or more "standard" timestamp/nonce checking approaches in the library but at the same time allow applications that have different needs to override them. There might be more likelihood of application interoperability if such standard techniques are widely available, too.
As with encryption, perhaps it make sense for these capabilities to be implemented in another library "on top of" a core library that only does verification of signatures... but this second library is still useful to flesh out at this point, I think.
Just a thought...
From: Yingdi Yu <yingdi at CS.UCLA.EDU<mailto:yingdi at CS.UCLA.EDU>>
Date: Tue, 17 Feb 2015 13:05:29 -0800
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
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<mailto:shijunxiao at email.arizona.edu>> wrote:
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?
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.
_______________________________________________ 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...
More information about the Nfd-dev