Project

General

Profile

Actions

Bug #1990

closed

SignedInterest: rejected if Interest is reordered

Added by Junxiao Shi over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Security
Target version:
Start date:
09/20/2014
Due date:
% Done:

100%

Estimated time:

Description

Background:

  • SignedInterest spec recommends a recipient (producer) to treat a signed Interest as invalid if its timestamp is less than or equal to the latest timestamp state of the public key.
  • Network does not require in-order delivery.

Steps to reproduce:

  1. create two signed Interests siA and siB signed by same key
  2. cause siA take a longer path in the network, so that siB is delivered to recipient before siA

Expected: both siA and siB are executed, in any order

Actual: siA is rejected

Suggested fixes:

  • recommend consumer to stop-and-wait: do not send the next signed Interest until the previous one is responded or InterestLifetime expires, OR
  • redesign replay protection so that it doesn't require in-order delivery
Actions #1

Updated by Yingdi Yu over 9 years ago

First, I will reject this one unless someone convinces me that there is such an app that really needs to generate more than 1000 signed interests.

Second, for app that may generate two signed interests in a short time, the problem can be easily avoided at the signing side. As in current KeyChain, we forbid assigning the same timestamp to two interests signed by the same key. We keep a soft state for used signing keys to remember the most recently used timestamp, if the timestamp assigned to the next interest happens to be the same as the last one, we will not assign the same timestamp, but assign (last_timestamp + 1).

Actions #2

Updated by Yingdi Yu over 9 years ago

I do not think the re-ordering problem exists as well. If the order really matters, then the interest sender should wait for the confirmation from the receiver side.

Actions #3

Updated by Junxiao Shi over 9 years ago

The solution in note-1 is irrelevant to this issue.

The solution in note-2 is same as the first suggested fix. This recommendation should appear in SignedInterest page.

Actions #4

Updated by Yingdi Yu over 9 years ago

but that is application's own problem, it is not a bug of the library.

Actions #5

Updated by Junxiao Shi over 9 years ago

It's neither a problem in application or in library. This bug is about the protocol, not any implementation of the protocol.

The protocol should acknowledge the network's lack of in-order delivery guarantee, and provide a recommendation about how to avoid rejected signed Interests due to out-of-order delivery.

Actions #6

Updated by Yingdi Yu over 9 years ago

There is no protocol of signed interest. It is just a format. How to use it is up to app...

Actions #7

Updated by Junxiao Shi over 9 years ago

In case SignedInterest page is a format instead of the protocol, delete the Signed Interest processing section from the page, and describe that in a separate protocol document, along with the stop-and-wait recommendation for consumers.

Actions #8

Updated by Junxiao Shi over 9 years ago

  • Target version set to v0.3

Yingdi acknowledged this bug at 20141201 conference call.

Actions #9

Updated by Yingdi Yu over 9 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Fixed the doc about signed interests.

Actions #10

Updated by Junxiao Shi over 9 years ago

  • Status changed from Resolved to Closed

I've verified SignedInterestProcessing rev1 gives a valid solution to this problem.

Actions

Also available in: Atom PDF