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

Mark Stapp mjs at cisco.com
Tue Feb 24 05:40:13 PST 2015


just to be clear - I was responding to the thread where use of a 
timestamp was being discussed. as you know, I'm all for Interests that 
actuate, and I'm all for high-functioning, application-friendly protocols.

-- Mark

On 2/23/15 6:07 PM, Alex Afanasyev wrote:
>
>> 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
>



More information about the Nfd-dev mailing list