Project

General

Profile

Feature #4650

Accept and store PrefixAnnouncement in rib/register command

Added by Junxiao Shi about 2 years ago. Updated 7 months ago.

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

40%

Estimated time:
6.00 h

Description

Including PrefixAnnouncement in RibMgmt rib/register command enables prefix propagation without NFD having to access the prefix owner's signing key.
This issue changes RibManager to accept the alternate command format, and also stores the PrefixAnnouncement element in the RIB entry so that readvertise component can retrieve it.


Related issues

Blocked by NFD - Feature #4649: Include PrefixAnnouncement in prefix registration commandsIn ProgressJunxiao Shi

Actions
Blocks NFD - Feature #4651: Prefix propagation: use stored PrefixAnnouncementNew

Actions
Blocks jndn - Feature #4652: Include PrefixAnnouncement in prefix registration commandsNew

Actions
Blocked by ndn-cxx - Feature #4804: Signed Interest v0.3Code reviewEric Newberry

Actions
#1

Updated by Junxiao Shi about 2 years ago

  • Blocked by Feature #4649: Include PrefixAnnouncement in prefix registration commands added
#2

Updated by Junxiao Shi about 2 years ago

  • Blocks Feature #4651: Prefix propagation: use stored PrefixAnnouncement added
#3

Updated by Junxiao Shi about 2 years ago

  • Blocks Feature #4470: Extend RIB for prefix announcement in self-learning added
#4

Updated by Junxiao Shi about 2 years ago

  • Blocks Feature #4652: Include PrefixAnnouncement in prefix registration commands added
#5

Updated by Junxiao Shi about 2 years ago

  • Blocks Feature #4683: add RIB entry update with prefix announcement in self-learning added
#6

Updated by Junxiao Shi about 2 years ago

  • Assignee set to Junxiao Shi
  • Target version set to v0.7

As I promised on 20180815 NFD call, I will provide code for Rib changes within 7 days after #4649 design is approved.

#7

Updated by Junxiao Shi about 2 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20
  • Estimated time changed from 3.00 h to 6.00 h

https://gerrit.named-data.net/#/c/NFD/+/4918 changes object ownership between rib::Service and RibManager. It fulfills most of #3818-23 design. This is a necessary preparation before PrefixAnnouncement changes.

#8

Updated by Junxiao Shi about 2 years ago

  • % Done changed from 20 to 30

https://gerrit.named-data.net/#/c/ndn-cxx/+/4921 encode and decode prefix announcement object. Please review API before I proceed further.

#9

Updated by Junxiao Shi about 2 years ago

  • % Done changed from 30 to 40

Change 4921 patchset 2 has PrefixAnnouncement decoding implementation. Encoding implementation comes next.

#10

Updated by Junxiao Shi about 2 years ago

Change 4921 patchset 4 has PrefixAnnouncement encoding implementation.

#11

Updated by Junxiao Shi about 2 years ago

https://gerrit.named-data.net/#/c/NFD/+/4931 puts incoming prefix announcements in Route, and provides outgoing prefix announcements from RibEntry. In case a RibEntry does not contain a Route with a PA, one will be made up for use in readvertisement (including self-learning's producer node).

#12

Updated by Teng Liang about 2 years ago

Junxiao Shi wrote:

https://gerrit.named-data.net/#/c/NFD/+/4931 puts incoming prefix announcements in Route, and provides outgoing prefix announcements from RibEntry. In case a RibEntry does not contain a Route with a PA, one will be made up for use in readvertisement (including self-learning's producer node).

If NFD can make up a PA, there is no need for end hosts to register a route using PA. I was thinking to add another registerPrefix API in ndn-cxx, for producers control the creation of PA. Just want to point out that there is no requirement from end points to use this feature.

#13

Updated by Junxiao Shi about 2 years ago

shouldn't the origin be prefix announcement?

Teng, can you help with this? It needs protocol update and declarations in ndn-cxx.

If NFD can make up a PA, there is no need for end hosts to register a route using PA.

NFD may not have a suitable key to sign the PA, see #4648.

I was thinking to add another registerPrefix API in ndn-cxx, for producers control the creation of PA.

This part is blocked by #4649 command format definition, which in turn is blocked by #4599. Self-learning does not depend on this (if you relax the trust schema or install the keys to NFD keychain), but Android depends on this (see #4648).

#14

Updated by Teng Liang about 2 years ago

Junxiao Shi wrote:

shouldn't the origin be prefix announcement?

Teng, can you help with this? It needs protocol update and declarations in ndn-cxx.

To make it clear, we are keeping one format of PA, which can used in both the rib/register command and NDNLP header, right?

What is exactly needed for protocol update (specific tasks)?

If NFD can make up a PA, there is no need for end hosts to register a route using PA.

NFD may not have a suitable key to sign the PA, see #4648.

What's the potential trust models?

I prefer the NFD to generate PA on behalf of the registered producers, using NFD's own keys:

  1. it does not require changes to end apps
  2. the trust model would be simpler?

I was thinking to add another registerPrefix API in ndn-cxx, for producers control the creation of PA.

This part is blocked by #4649 command format definition, which in turn is blocked by #4599. Self-learning does not depend on this (if you relax the trust schema or install the keys to NFD keychain), but Android depends on this (see #4648).

If NFD makes up PA, there is not need to change registerPrefix API in ndn-cxx.

#15

Updated by Junxiao Shi about 2 years ago

What is exactly needed for protocol update (specific tasks)?

See #4280-83.

What's the potential trust models?

Testbed routers enforce hierarchical trust model, so NFD-Android has to let application create the PA, see #4648.

Self-learning is more flexible because it does not involve testbed routers. We can start with:

  1. From enterprise CA (a CA trusted by every node in the local area network), issue an announcement signing certificate to each node.
  2. In the trust schema, set trust anchor to enterprise CA (or its issuer), and set rules so that any announcement signing certificate can sign any PA.

The better solution is in self-learning dissertation.
Since this question is out of scope of #4650, I will not post further answers here. If you want more discussion, please email nfd-dev mailing list.

#16

Updated by Teng Liang about 2 years ago

Junxiao Shi wrote:

Self-learning is more flexible because it does not involve testbed routers.

I agree with this. So in self-learning, the producers can be unaware of PA, and the NFD they connect to will help them to create PA.

#17

Updated by Teng Liang about 2 years ago

[Bug] The data returned by PrefixAnnouncement::toData does not have the tlv::ContentType_PrefixAnn content type.

#18

Updated by Junxiao Shi about 2 years ago

[Bug] The data returned by PrefixAnnouncement::toData does not have the tlv::ContentType_PrefixAnn content type.

Fixed in https://gerrit.named-data.net/#/c/ndn-cxx/+/4943

#19

Updated by Teng Liang about 2 years ago

self-learning is still waiting for this to finish.

#20

Updated by Junxiao Shi about 2 years ago

  • Blocks deleted (Feature #4470: Extend RIB for prefix announcement in self-learning)
#21

Updated by Junxiao Shi about 2 years ago

  • Blocks deleted (Feature #4683: add RIB entry update with prefix announcement in self-learning)
#22

Updated by Davide Pesavento about 1 year ago

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

Updated by Junxiao Shi 8 months ago

#24

Updated by Junxiao Shi 8 months ago

PrefixAnnouncement rev8 defines the rib/announce command (variant of rib/register that accepts PrefixAnnouncement) to use signed Interest. Therefore, this issue is blocked by #4804 signed Interest implementation.

#25

Updated by Junxiao Shi 7 months ago

2020-03-12 NFD call reviewed PrefixAnnouncement rev9 design.
It's found that the rationale of using signed Interest is questionable.

  1. PrefixAnnouncement object already contains a signature and has limited validity period.
  2. While using signed Interest v0.3 could protect against replay attacks, such protection is only possible if NFD-RIB can trust the signing key of the signed Interest.
  3. In #4648 use case, the signing key trusted by the receiving NFD-RIB (i.e. testbed) is only present at the application, which signed the PrefixAnnouncement object. NFD-Android does not possess the trusted signing key, and therefore cannot produce signed Interests that can prove to not to be part of a replay attack.

If we eliminate signed Interest and revert to parameterized Interest only, an attacker could retrieve the PrefixAnnouncement object by expressing an Interest of its name, and then send a rib/announce command before the victim does.

Also available in: Atom PDF