Project

General

Profile

Feature #4685

Make nonce optional in packet format v0.3 encoding

Added by Arthi Padmanabhan over 2 years ago. Updated 7 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Base
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

Packets are encoded as v0.3 if the parameters element is present, but getNonce() still generates a nonce if there is none. In v0.3, nonce is optional, so this issue is to stop creating a nonce if none was set. This is part of Packet03Transition.

#1

Updated by Davide Pesavento over 2 years ago

  • Tracker changed from Task to Feature
  • Start date deleted (07/26/2018)
#2

Updated by Junxiao Shi almost 2 years ago

  • Tags set to Packet03Transition
  • Description updated (diff)
#3

Updated by Davide Pesavento over 1 year ago

  • % Done changed from 0 to 30

https://gerrit.named-data.net/c/ndn-cxx/+/5723 This is the first step: no longer force the generation of a nonce during decoding if the Interest doesn't contain one. The packet spec v0.3 says:

Nonce is required when an Interest is transmitted over the network links, i.e., a compliant forwarder must augment the Interest with the Nonce element if it is missing.

I'm assuming NFD calls getNonce() at some point before forwarding an Interest. If that's the case, getNonce will invalidate the cached encoding and this will trigger a re-encode with the generated nonce when the Interest is sent. Otherwise, we need to force nonce generation in NFD somehow.

#4

Updated by Davide Pesavento about 1 year ago

  • Target version changed from v0.7 to v0.8
#5

Updated by Eric Newberry 7 months ago

  • Assignee set to Eric Newberry
#6

Updated by Eric Newberry 7 months ago

  • Status changed from New to In Progress
#7

Updated by Eric Newberry 7 months ago

Question: In the NFD changes needed for this, how does the dead nonce list work if there's no nonce an the incoming Interest? Perhaps we can just skip checking the list in that case?

#8

Updated by Eric Newberry 7 months ago

  • Status changed from In Progress to Code review
  • % Done changed from 30 to 70
#9

Updated by Junxiao Shi 7 months ago

how does the dead nonce list work if there's no nonce an the incoming Interest?

The easiest way is to generate a random Nonce upon entering forwarding. Then you don't need to change any other procedures.

#10

Updated by Eric Newberry 7 months ago

Junxiao Shi wrote in #note-9:

how does the dead nonce list work if there's no nonce an the incoming Interest?

The easiest way is to generate a random Nonce upon entering forwarding. Then you don't need to change any other procedures.

It looks like this would already be done when checking against the dead nonce list, since that calls getNonce(). No changes to NFD needed then?

#11

Updated by Davide Pesavento 7 months ago

This task was only loosely defined. We should agree on the way forward before implementing/changing anything. I see at least 4 possible ways to move forward:

  1. getNonce() stops generating a nonce if one isn't present, changing the return type to something like optional<Nonce>. Then either (1a) ndn-cxx generates a nonce before sending the packet or during Interest encoding, or (1b) NFD generates a nonce upon receiving a nonce-less Interest. This probably requires adding a new Interest method to explicitly generate a nonce.
  2. Keep the current getNonce() semantics, disable nonce generation during Interest encoding, but keep it in Face::expressInterest(). (This is Eric's patch)
  3. Same as (2) but also disable nonce generation in Face. This means all Interests emitted by ndn-cxx will be nonce-less, unless explicitly added.
  4. Do nothing, keeping the status quo of always generating a nonce during Interest encoding. This behavior is still compliant with the packet format spec.

I have a slight preference for (1a) or (4). I think (2) would be sub-optimal as it may cause an extra encoding for the same packet. (1b) and (3) would move the burden of nonce generation (and therefore packet re-encoding) to NFD for all packets created by ndn-cxx applications.

Irrespective of this decision, I think we should make sure NFD properly handles nonce-less Interests and add unit tests for this case if not already there.

#12

Updated by Alex Afanasyev 7 months ago

My preference is (4). The intention of the spec change was to allow receiving nonce-less Interests and add nonce automatically, but this doesn't imply we should give NFD Interest without nonce from our library. Yes, NFD needs to ensure that nonce exists and add it when missing, but this should be more like an exceptional path, than a norm.

#13

Updated by Eric Newberry 7 months ago

I also have a preference for (4) and agree we need to add a test case in NFD for receiving a packet with no nonce.

#14

Updated by Davide Pesavento 7 months ago

  • Status changed from Code review to Closed
  • % Done changed from 70 to 100

The NFD test case has been merged. Consensus seems to be that no other changes are needed at this time. Closing.

Also available in: Atom PDF