NFD

Change 4921 patchset 4 has PrefixAnnouncement encoding implementation.

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).

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.

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).

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.

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.

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.

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

[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

self-learning is still waiting for this to finish.

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.

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.

Davide Pesavento wrote in #note-28:

Junxiao Shi wrote in #note-27:

I've lost hope for this to ever happening in NFD, and do not plan to work on this issue further.

Well, you were the assignee, so you were responsible for this task. Saying "I've lost hope" means that you gave up on it.

There has been pushbacks on the protocol design, which cannot be resolved anytime soon.