NFD

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.

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.

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.

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.

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.

+1

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

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.