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

[Burke, Jeff]

As part of early lighting control work, we had already proposed an authenticated interest approach that includes sequence #, timestamp, and RTT estimator as state to avoid replay attacks:
http://named-data.net/publications/nomen13/<http://named-data.net/wp-content/uploads/nomen13.pdf>
(see p4).

(I am not sure why SignedInterest doesn't provide at least an optional sequence number....  Can the ndn-cxx/architecture folks comment on why this was removed from the design?)

Thanks,
Jeff

From: <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>
Date: Mon, 23 Feb 2015 17:54:46 +0000
To: <mjs at cisco.com<mailto:mjs at cisco.com>>
Cc: <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 think if a protocol needs serialized commands, it should have its own serial number and not confound protocols by using a field from a different area of concern.  For example, if you change signing algorithms that use a different mechanism, will that break your protocol?

I think the signing algorithm and verification should use its own mechanism.  Other protocols should not peek in to there for their properties. For example, some system might ditch the existing signature and put a new signature on there.  That should not change your protocol’s behavior.

Marc

On Feb 23, 2015, at 9:50 AM, Mark Stapp <mjs at cisco.com<mailto:mjs at cisco.com>> wrote:

it

_______________________________________________ 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...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150223/4b985381/attachment.html>