NFD

The protocol should be updated to reflect this requirement before the implementation change.

Is it possible for two commands specifying face 0 to collide? This would require two faces with the same key to send commands at the same time (millisecond or at least appear that way from clock skew?). However, the consequence is an annoying to debug problem: both faces will receive a "success" control response, so the second face will think they succeeded in adding themselves even though they did not.

Also, the configuration file format should probably require authorizations to be in the context of faces (i.e. this key is authorized issue commands {A, B, C, ... } on faces {X, Y, Z, ...}). Does this have consequences for supporting FaceId == 0? I think the authorizer (security library?) would need to have inbound face object as well as the command.

FaceId == 0 is not currently supported by the current code path. Just to put (some of) the required changes in context:

The UML defines FibManager.onFibRequest as only taking an Interest (no face information). Similarly, InternalFace.sendInterest (which invokes onFibRequest) only takes an Interest as an argument and therefore has no face information.

I believe sendInterest is invoked by Forwarder.onOutgoingInterest who also does not explicitly have the incoming face (only outgoing). It does have the PIT entry, which theoretically only has 1 incoming face, but I wouldn't want to rely on that.

onOutgoingInterest is invoked by Strategy.sendInterest. Once again, it has a PIT entry, but no explicit incoming face. It looks like the last piece in the chain to have the incoming face information is BestRouteStrategy.afterReceiveInterest (which calls Strategy.sendInterest).

There may be other changes as well (e.g. OnInterest as defined in AppFace).

Thoughts?

Response section in Face management and Fib management specs are updated

Is it possible for two commands specifying face 0 to collide? This would require two faces with the same key to send commands at the same time (millisecond or at least appear that way from clock skew?). However, the consequence is an annoying to debug problem: both faces will receive a "success" control response, so the second face will think they succeeded in adding themselves even though they did not.

Ideally, each application should use its own key to send the command. Practically... I had similar problem in ndnd-tlv, but the protocol there didn't have timestamps at all. We could add random number somewhere to ControlCommand (and/or SignedInterest) spec, in addition to timestamp.

The UML defines FibManager.onFibRequest as only taking an Interest (no face information). Similarly, InternalFace.sendInterest (which invokes onFibRequest) only takes an Interest as an argument and therefore has no face information.

This problem is actually almost solved, I just didn't get to finalizing the solution. Interest/Data abstractions now have get/setIncomingFaceId methods, which will be used internally in NFD (probably as a first thing in the Forwarder) to get information about the Interest/Data incoming path, which can be then used by Fib manager to process the request.

Junxiao Shi wrote:

A collision among multiple commands are unlikely, because signed Interests should use a random number for the signature, even if options and timestamp are identical.

Actually, unless we specifically add randomness, it is NOT automatically added by the signing process. Signing twice the same piece of data results in exactly the same result.

If agreed, I would update signed Interests spec to include random number after the timestamp field.

Signed Interests are now renamed to Command Interests. The reason is that Signed Interests are kind of general name for Interests that are signed, while Command Interests are the same signed Interests but with additional assurances that each command is unique and there is a timestamp to protect against replay attacks.

The random value does not completely solve the problem. The ultimate solution is to prevent application from generating command interest with the same command, the same timestamp and the same signature. Otherwise, if legitimate applications send two interests containing the same command and timestamp and signature but different random values, then which interest is valid? We cannot treat both of them as valid, because that is completely against the usage of timestamp. If one of the interests is treated as valid, then the other interest is "mistaken" as invalid.

Although we will provide random value in Command Interest, it is strongly recommend that different apps use different keys/certs, and avoid using the same timestamp in a sequence of same commands.

The solution that "random-value" provides is a "guarantee" that the command will reach the command processor and that the retrieved answer is to the issued command, not another command from somebody else. I agree with Yingdi that apps should use different keys, but for now if one of the apps see "failure", that would be a good for such an improbable case (after failure apps can re-try if the want).

What the library will do (must do) is to ensure that the same app will never issue command interest with the same timestamp, even if commands are created at the same time. For this, the library will (must) have a state.