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

[Mark Stapp]

I'm sorry - I'm not following how this can be a realistic problem. if 
you have an application that serializes its commands, then ... each 
command _must_ have some serial number associated with it, yes? that 
sort of _must_ be monotonic, so that a receiver can determine whether a 
gap has appeared. a timestamp is not a substitute for a monotonic 
counter, because the receiver cannot detect a gap immediately. if an 
incoming message introduces a gap, the application (or a parameter to 
the security library) needs to determine whether that message can be 
processed immediately, as if it were idempotent. otherwise, there will 
out-of-order processing if any messages are reordered. if "green" is 
message #3 and it arrives before the receiver has seen "red" (#2), then 
the receiver can't just apply #3, that would be just ... wrong.

-- Mark


On 2/21/15 12:11 AM, Junxiao Shi wrote:
> Hi Lan
>
> The replay attack scenario requires the attacker to have the ability to
> block the transmission of an earlier command.
>
>  1. An legit client sends command "1. set light to red".
>  2. Attacker in the middle intercepts this command, and prevents it from
>     being delivered to the light.
>  3. The legit client sends command "2. set light to green".
>  4. Attacker forwards this command to the light.
>  5. Attacker sends the command intercepted in step 2 to the light.
>
>
> Yours, Junxiao
>
> On Tue, Feb 17, 2015 at 1:07 PM, Lan Wang (lanwang) <lanwang at memphis.edu
> <mailto:lanwang at memphis.edu>> wrote:
>
>>     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)?
>>     The risk is: an attacker can intercept (and block the transmission
>>     of) an earlier command, and replay it later.
>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>