[Ndn-interest] [Clue] A Cloud-Applicable Network Policy Enforcement Strategy using Named Data
shijunxiao at email.arizona.edu
Sat Sep 20 10:10:17 PDT 2014
In signed Interest
- timestamp is to prevent replay attack: the timestamp in a new command
must be greater than any existing timestamps
- nonce is to guarantee uniqueness; this is useful when producer is not
checking the timestamp
Each consumer is expected to have its own unique keypair. Under this
assumption, the system can tolerate a clock skew of 60 seconds between
consumer and producer.
Millisecond granularity is sufficient for the intended usage of signed
Interest - infrequent command execution.
Also note that the timestamp is never compared to wallclock after the
initial command. Therefore, the consumer can operate as follows to send
1. the initial command must carry a timestamp equal to wallclock
2. in each subsequent command, increment timestamp by 1
3. in case a command is rejected due to invalid timestamp, it means
latest timestamp state is lost on the producer, therefore consumer should
resend the command as an initial command (step 1)
But this doesn't solve all problems with high-frequency signed Interests.
See bug 1990 <http://redmine.named-data.net/issues/1990>.
On Sat, Sep 20, 2014 at 1:06 AM, Tai-Lin Chu <tailinchu at gmail.com> wrote:
> > I hope you could read the spec of signed interest carefully and think a
> little bit more before making the claim above.
> sorry, I was making an extreme example of unsynced clock (I know that
> nfd uses unix UTC time).
> Btw, do you know why we have both nonce and timestamp in signed
> interest? Will seq no alone solve this problem? I am worried that msec
> might not be sufficient in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest