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

[Alex Afanasyev]

> On Feb 23, 2015, at 9:50 AM, Mark Stapp <mjs at cisco.com> wrote:
> 
> 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.

The use case for the signed interests wasn't to support arbitrary sequences of the commands.  It was rather to support a spurious commands that are send out from time to time, generated by a distributed set of commanders.  In this case, sequence number doesn't always make sense, as it can be unknown for the commander.

When multiple control actions need to be performed, use of (signed) interests is not, in my opinion, appropriate.  In this case, it make sense to send a control command that initiates fetching of a sequence of control commands, which, given they are explicitly requested by the control unit, can be properly ordered and executed in a proper order.  In this protocol, there is no need for any kind of timestamp, because commands are requested, not unsolicitedly received.


---
Alex

> -- 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
>> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150223/5245e127/attachment.bin>