CommandInterest » History » Revision 2
Revision 1 (Yingdi Yu, 05/25/2015 01:45 PM) → Revision 2/10 (Yingdi Yu, 05/25/2015 02:09 PM)
CommandInterest =============== **Command Interest** is an extension of [[SignedInterest|Signed Interest]]. As The signature of a signed interest, a command interest encodes the SignatureInfo and SignatureValue Interest packet is embedded into the last two components component of the Interest name. The signature covers a continuous block starting from the first name component TLV to the penultimate name component TLV: +-------------+----------+-----------------------------------------------------------------------------------+ | Interest | Interest | +------+--------+--------------------------------------------------+ +----------+ | | Type (0x01) | length | | Name | Name | +---------+-- --+---------+---------+---------+| | Other | | | | | | Type | Length | |Component| ... |Component|Component|Component|| | TLVs ... | | | | | | | | | TLV 1 | | TLV n-2 | TLV n-1 | TLV n || | in | | | | | | | | +---------+-- --+---------+---------+---------+| | Interest | | | | | +------+--------+--------------------------------------------------+ +----------+ | +-------------+----------+-----------------------------------------------------------------------------------+ \ /\ / ---------------- ------------------ --- --- \/ \/ Signed portion of Interest Signature A command interest must prevent replay attack, therefore a command interest may encode additional components before More specifically, the SignatureInfo component. Depending on specific communication models, the command interest may introduce different name components. We introduce one of the simplest solutions, **stop-and-wait**: ## stop-and-wait A stop-and-wait command interest introduces two SignedInterest is defined to have four additional components: * ``<timestamp>`` * ``<nonce>`` * ``<SignatureInfo>`` * ``<SignatureValue>`` For example, for ``/command/interest/name`` ``/signed/interest/name`` name, CommandInterest will be defined as: /command/interest/name/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> /signed/interest/name/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> \ /\ / ------------ ----------------------------- ----------- --------------- -------------- -------------------------- \/ \/ Command Interest Extension Components Additional components of Signed Interest ## Signed Interest specific Name components ### Timestamp component (n-3 *th*) The value of the n-3 *th* component is the interest's timestamp (in terms of millisecond offset from UTC 1970-01-01 00:00:00) encoded as [nonNegativeInteger](http://named-data.net/doc/ndn-tlv/tlv.html#non-negative-integer-encoding). The timestamp may be used to protect against replay attack. ### Nonce component (n-2 *th*) The value of the n-2 *th* component is random value (encoded as [nonNegativeInteger](http://named-data.net/doc/ndn-tlv/tlv.html#non-negative-integer-encoding)) that adds additional assurances that the interest will be unique. ### Command Interest Processing SignatureInfo component (n-1 *th*) **Note that this verification process require signed interest to be received in order. The value of the n-1 *th* component is actually a [SignatureInfo](http://named-data.net/doc/ndn-tlv/signature.html) TLV. +---------+---------+-------------------+ |Component|Component| +---------------+ | | Type Applications adopting this process may want to take "stop-and-wait" strategy.** | Length | | SignatureInfo | | | | | | TLV | | | | | +---------------+ | +---------+---------+-------------------+ | | |<---------The n-1 th Component-------->| On receiving an Interest, the producer, after verifying the packet signature, should treat the Interest as invalid in the following three cases: ### SignatureValue component (n *th*) - one The value of the two components above (Timestamp and Nonce) n *th* component is missing or cannot be parsed correctly; - the timestamp is **equal or earlier** than the timestamp of the received one has been received before. actually a [SignatureValue](http://named-data.net/doc/ndn-tlv/signature.html) TLV. +---------+---------+--------------------+ |Component|Component| +----------------+ | | Type | Length | | SignatureValue | | | | | | TLV | | | | | +----------------+ | +---------+---------+--------------------+ | | |<----------The n th Component---------->| ## Signed Interest Processing Note that in order How to detect this situation, the recipient needs to maintain a *latest timestamp* state for each trusted public key (**Since public key cryptography is used, sharing private keys is not recommended. If private key sharing is inevitable, it is the key owner's responsibility to keep clock synchronized**). For each trusted public key, the state is initialized as the timestamp of the first valid Interest verify signed by interest may vary among applications, depending on the key. Since then, the state will application specific communication model. One possible processing style can be updated every time when the recipient receives a valid signed Interest. Note that for the first Interest, the state is not available. To handle this special situation, the recipient should check the Interest's timestamp against a grace interval (e.g., 120 seconds) [current\_timestamp - interval/2, current\_timestamp + interval/2]. The first interest is invalid if its timestamp is outside of the interval. found [here](http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing).