Project

General

Profile

Feature #4649

Include PrefixAnnouncement in prefix registration commands

Added by Junxiao Shi over 1 year ago. Updated 12 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Protocol
Target version:
Start date:
Due date:
% Done:

70%

Estimated time:
2.00 h

Description

In RibMgmt rib/register command, define an alternative parameter format that a PrefixAnnouncement element is included in place of the Name.
Similar a PrefixAnnouncement contains a signature by the prefix owner, NFD prefix propagation feature may include this PrefixAnnouncement when readvertising the prefix, without having to access the signing key itself.

This issue involves protocol definition only. Implementation are in separate issues.


Related issues

Blocks NFD-android - Bug #4648: Prefix propagation does not work with app-owned certificateNew

Actions
Blocks NFD - Feature #4650: Accept and store PrefixAnnouncement in rib/register commandIn Progress

Actions
Blocked by NDN Specifications - Feature #4599: Redesign Signed Interest and Command Interest for packet format v0.3Closed

Actions

History

#1

Updated by Junxiao Shi over 1 year ago

  • Blocks Bug #4648: Prefix propagation does not work with app-owned certificate added
#2

Updated by Junxiao Shi over 1 year ago

Previously, a prefix registration command has a timestamped signature by the prefix owner (although the "by the prefix owner" part wasn't implemented correctly, see #2856), and the signature is valid for about ten seconds: if an attacker replays the command later, the authenticator won't accept the command.

In self-learning, PrefixAnnouncement is valid for at least a few hours, so that an off-path cache can announce itself as a potential content source. In the full design http://hdl.handle.net/10150/625652, the announcement encloses a trust schema for application contents under the announced prefix, so that routers may verify those contents (upon report by consumer) and cut off attackers who attempt to inject invalid contents (as determined by the trust schema).

If we adapt PrefixAnnouncement for prefix propagation scenario, it is unlikely to also require the enclosed trust schema, and thus we need a different way to prevent replay attacks. The easiest way is to shorten the validity period of the PrefixAnnouncement to less than a minute. It is similar to today's timestamped prefix registration commands, but the validity period is slightly longer than "several seconds" because the same PrefixAnnouncement might travel between more than two nodes.

#3

Updated by Junxiao Shi over 1 year ago

  • Blocks Feature #4650: Accept and store PrefixAnnouncement in rib/register command added
#4

Updated by Junxiao Shi over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Junxiao Shi
  • Target version set to v0.7
  • % Done changed from 0 to 50
  • Estimated time set to 2.00 h

PrefixAnnouncement rev1.

I decide to introduce a new command verb rib/announce rather than overloading rib/register. This simplifies command validation, and allows the new protocol to use Interest Parameters.
The Dispatcher only needs a small update to support this format.

#5

Updated by Alex Afanasyev over 1 year ago

unannounce => withdraw

For announce, I am a bit at loss with the format of the interest. I thought we agreed to bundle everything as part of ControlParameters component. Control Parameters will go directly to Interest Parameters as soon as we finish the updated definition of the new Signed Interest and its implementation. Updating two variants of control commands would be extra and unnecessary work.

For spec, we don't need to mention "NFD-RIB converts this command into an equivalent rib/register command.".

Don't quite like that "A prefix announcement object, by default, is valid indefinitely.". I think we should prohibit such object. Also, I don't think there is any value of overloading FreshnessPeriod and InterestLifetime with a completely new semantics. Just define new fields for semantics.

#6

Updated by Junxiao Shi over 1 year ago

unannounce => withdraw

I wanted to avoid conflict with NLSR_Management, but it turns out not a problem because the noun (rib vs prefix-update) is different.
In any case, this command does not exist.

Updating two variants of control commands would be extra and unnecessary work.

This protocol does not use ControlCommand. PrefixAnnouncement type would be a subclass of ndn::mgmt::ControlParameters to be compatible with Dispatcher, but is not a subclass of ndn::nfd::ControlParameters.
Collecting unrelated fields into a single ndn::nfd::ControlParameters type was a mistake, and I intend to correct this mistake starting from this protocol.

Control Parameters will go directly to Interest Parameters as soon as we finish the updated definition of the new Signed Interest and its implementation.

Eventually I want to avoid double signing. The signature on prefix announcement object is sufficient. No need to outer signature on the signed Interest.
I kept with Command Interest because Dispatcher does not support otherwise.

For spec, we don't need to mention "NFD-RIB converts this command into an equivalent rib/register command.".

Fine.

Don't quite like that "A prefix announcement object, by default, is valid indefinitely.". I think we should prohibit such object.

rib/register command without ExpirationPeriod parameter is valid indefinitely. This is the same.
Of course the prefix announcement object cannot be used to create new prefix registrations once its signing certificate expires.

Also, I don't think there is any value of overloading FreshnessPeriod and ValidityPeriod with a completely new semantics. Just define new fields for semantics.

These are not new semantics, but exactly same semantics as the elements are originally intended for.

#7

Updated by Junxiao Shi over 1 year ago

Don't quite like that "A prefix announcement object, by default, is valid indefinitely.". I think we should prohibit such object. Also, I don't think there is any value of overloading FreshnessPeriod and InterestLifetime with a completely new semantics. Just define new fields for semantics.

PrefixAnnouncement rev3 replaces FreshnessPeriod with ExpirationPeriod, and makes ExpirationPeriod required so that a prefix announcement cannot be valid forever. It's insufficient to require either ExpirationPeriod or ValidityPeriod, because that would cause a prefix announcement to become valid indefinitely on a receiver without UnixTime clock.
Also, both ExpirationPeriod and ValidityPeriod are in the Content element rather than MetaInfo or SignatureInfo, because there's no reason to have them out of Content.

#8

Updated by Junxiao Shi over 1 year ago

As discussed in 20180820 call, the keyword prefix-announcement is too long.
I'm shortening it to 32=PA in PrefixAnnouncement rev4, NameComponentType rev10, and ContentType rev8.

#9

Updated by Alex Afanasyev over 1 year ago

+1

#10

Updated by Teng Liang over 1 year ago

What's the relationship between this prefix announcement and the one in NDNLP? Are you going to replace the other one with this one?

#11

Updated by Junxiao Shi over 1 year ago

  • Blocked by Feature #4599: Redesign Signed Interest and Command Interest for packet format v0.3 added
#12

Updated by Junxiao Shi over 1 year ago

What's the relationship between this prefix announcement and the one in NDNLP? Are you going to replace the other one with this one?

This prefix announcement replaces the prefix announcement header in NDNLPv2. As I explained in 20180820 call, I expect Teng to implement the code changes in ndn-cxx/src/lp and NFD/daemon/face; use #4280 for these changes.

#13

Updated by Davide Pesavento 6 months ago

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

Updated by Junxiao Shi 12 days ago

  • % Done changed from 50 to 70

PrefixAnnouncement rev8 updates the syntax of rib/announce command to match v0.3 signed Interest format.

Also available in: Atom PDF