NFD

In today's NFD call, we discussed that NFD should take the prefix registration from an NDN application as the prefix announcement.

NFD should take the prefix registration from an NDN application as the prefix announcement.

This is correct, but irrelevant to this issue that governs the format of an announcement.

Reply to note-5:

The definitions should be updated into NDNLPv2 directly.
You'll need to include what the signature covers.

Junxiao Shi wrote:

Reply to note-5:

The definitions should be updated into NDNLPv2 directly.

I don't see an advantage of updating NDNLPv2 before we reach an agreement. What's the problem of discussing the design here?

You'll need to include what the signature covers.

The signature is well-defined in the NDN-TLV doc.

What's the problem of discussing the design here?

I need to see the specification within context.

You'll need to include what the signature covers.

The signature is well-defined in the NDN-TLV doc.

That definition is inapplicable because the proposed PrefixAnnouncement struct contains neither MetaInfo nor Content.

Junxiao Shi wrote:

What's the problem of discussing the design here?

I need to see the specification within context.

Why? The PrefixAnnouncement has nothing to do with other fields. It is clearer to put it here like note-5.

You'll need to include what the signature covers.

The signature is well-defined in the NDN-TLV doc.

That definition is inapplicable because the proposed PrefixAnnouncement struct contains neither MetaInfo nor Content.

This is how signed Interest defines the its SignatureInfo and SignatureValue. In both cases, MetaInfo and Content are empty. There is no need to create a different TLV.

Header definition
LpHeaderField ::= .. | PrefixAnnouncement
PrefixAnnouncement ::= PREFIXANNOUNCEMENT-TYPE TLV-LENGTH
                                       Name
                                       SignatureInfo
                                       SignatureValue

The SignatureInfo TLV is defined here, while the SignatureValue TLV is defined here except that MetaInfo and Content are excluded for the signature calculation.

TLV-TYPE Number Assignments
Type: PrefixAnnouncement
number(decimal):848
number(hex):0x0350

Junxiao Shi wrote:

I need to see the specification within context.

The NDNLPv2 doc is updated with the prefix announcement specification. Can you take a look?

Given that prefix announcement is similar to signed Interest, the source code of signed Interest may help me to implement the prefix announcement. However, I couldn't find signed Interest in ndn-cxx. Is security/v2/command-interest-signer the equal one?

Similar to a Data packet, an unsigned prefix announcement should be recognized and handled. People may use unsigned prefix announcements for experiments purpose.

the source code of signed Interest may help me to implement the prefix announcement. However, I couldn't find signed Interest in ndn-cxx

Interest signing is exposed as KeyChain::sign API and is implemented in the TPM.

Similar to a Data packet, an unsigned prefix announcement should be recognized and handled.

There's no such thing as a "unsigned Data packet". Data packet is always signed, although the signature may be invalid.
Prefix announcement shall be the same: it must always contain a signature, but the recipient can choose not the validate it.

Our design is that when a producer registers a prefix with an NFD. A prefix announcement should be created and bound with the prefix. However, the prefix registration is for the main FIB. As we choose to use measurement table for the self-learning to serve as its private FIB, should the self-learning forwarding strategy (on the NFD connected to the producer) create a private FIB entry according to main FIB entry?

Teng Liang wrote:

should the self-learning forwarding strategy (on the NFD connected to the producer) create a private FIB entry according to main FIB entry?

I'm not sure I understand the question. Why would that be needed?

I am not sure how the first prefix announcement is created (by whom) and stored ?

Teng Liang wrote:

I am not sure how the first prefix announcement is created (by whom) and stored ?

I thought that was a design question that you discussed some time ago... If I remember correctly, it was decided that the library (ndn-cxx) should take care of that. I'm still somewhat confused though because this has nothing to do with your question in note-16, where you were talking about the forwarder.

I was thinking that in self-learning a prefix announcement should be stored with a FIB entry. As self-learning uses measurement table as its FIB (is measurement table only accessed by a forwarding strategy?), self-learning needs to do the operation (storing a prefix announcement in its private FIB).

Second, when a producer registers a prefix with an NFD, a FIB entry will be created (in the main FIB). Some one (the self-learning forwarding strategy) should create a prefix announcement (use the library) according to the main FIB entry. Does it make sense?

Note that this issue is about the encoding of prefix announcement. It has nothing to do with who generates them or where they are stored.

Alex suggests use a Data with empty Content and empty MetaInfo wrapped in a PrefixAnnouncement LP header field, to avoid a reinvention of the wheel.

use a Data with empty Content and empty MetaInfo wrapped in a PrefixAnnouncement LP header field, to avoid a reinvention of the wheel.

What "wheel" are you talking about? The major concern for encoding a prefix announcement as Data is the number of octets it takes, given LpHeaderField cannot be fragmented.

Taking a step back: do you have a clear picture about how the trust model would look like, and would you enforce it in a real deployment?
If not, I recommend dropping the signature part altogether, and define the prefix announcement to be:

PREFIX-ANNOUNCEMENT := PREFIX-ANNOUNCEMENT-TYPE TLV-LENGTH
                         PREFIX-LENGTH-TYPE TLV-LENGTH
                           nonNegativeInteger

The number indicates the first k components of the Data name is the producer's prefix.
It is wrapped in a PrefixLength element, so that in the future we can define something else under PrefixAnnouncement element to have a signature.

I am seriously against creating another "data packet", signing of the new data packet, verification for the new data packet, all the processes in all validators for the new data packets. It is wrong and redundant, as highlights that data packet is not universal data structure to carry data. Also, 4 bytes of "overhead" is barely anything compared to signature and name size.

as highlights that data packet is not universal data structure to carry data

The existence of SignedInterest has demonstrated that Data packet is not universal data structure to carry data. If Data was universal, the parameters and signature would be carried in a Data packet appearing as a name component or payload of the Interest.

4 bytes of "overhead" is barely anything compared to signature and name size

It is still overhead. Small things add up.

This is not a good example. Signed interest is signed request and only exist because we cannot send data packet to request data packet. There is nothing that inherently not "data" with prefix announcement, making it exactly the same data packet with just for no reason a slightly different definition. If you don't like the trivial overhead, you can suggest making MetaInfo and Content optional for data packet spec.

Signed interest is signed request and only exist because we cannot send data packet to request data packet.

Why not: /prefix/[Data packet with command name, parameters, and signature] ?

There is nothing that inherently not "data" with prefix announcement

Actually, prefix announcement is Data in my publication.
But I want an answer to my second question in note-25.

Junxiao Shi wrote:

Taking a step back: do you have a clear picture about how the trust model would look like, and would you enforce it in a real deployment?
If not, I recommend dropping the signature part altogether

The design should allow a real deployment to apply any trust model, thus the prefix announcement has to have a signature. The current trust model we take is that when a producer registers a prefix with an NFD, the prefix announcement is automatically created somewhere and self-learning can simply use it.

The current prefix announcement is basically a Data packet, except that it has no metadata and content. I see no convincing reason not to use the Data structure for prefix announcement. Thus, I agree with Alex and will take note-24 to implement prefix announcement.

The design should allow a real deployment to apply any trust model, thus the prefix announcement has to have a signature.

How to apply a trust schema in your implementation? Where do I input the trust schema?

The current trust model we take is that when a producer registers a prefix with an NFD, the prefix announcement is automatically created somewhere

Where, exactly?

and self-learning can simply use it.

How to validate the signature against the trust schema? How to retrieve certificates, from within the forwarding strategy?

Without concrete answers to the above questions, why not take a simpler approach and just use a “prefix length” field? It has no conflict with a future expansion to include a signature or a full Data packet.

Junxiao Shi wrote:

PREFIX-ANNOUNCEMENT := PREFIX-ANNOUNCEMENT-TYPE TLV-LENGTH
                         PREFIX-LENGTH-TYPE TLV-LENGTH
                           nonNegativeInteger

The number indicates the first k components of the Data name is the producer's prefix.

Isn't that a huge security hole?

Isn't that a huge security hole?

The security hole is no larger than a signed object without any verification. Anyone can forge either one.

Let's take a step back. Self-learning is more than a forwarding strategy, because it also does routing work (e.g., routing verification and updates). At this point, I feel RIB should be the right guy to handle the routing part of self-learning. We wanted to bypass RIB, because it may involve a lot of code changes. However, doing things in a right way saves more efforts (seems that bypassing RIB is not a right way to go, and it ends up with building another RIB).

Regarding self-learning's trust model, here is my picture:
a producer registers a prefix with a local NFD. The local NFD should be able to verify the registration. This part is not of self-learning's business, but I assume whatever registered in an NFD is trusted. Then, connected NFDs should have some kind of trust model among each other, e.g., trusting only neighbors or every one in the network. As a prefix announcement is generated by an NFD, it can be verified by another NFD.

Here is the role of RIB in this game:
RIB needs to handle the routing part of self-learing. A fowarding strategy asks RIB for everything related to routing, e.g., get a prefix announcement, register a FIB entry with a prefix announcement, update a FIB entry, etc. It also means that RIB has to create and verify a prefix announcement, and accept an input of trust schema.

Junxiao Shi wrote:

Isn't that a huge security hole?

The security hole is no larger than a signed object without any verification. Anyone can forge either one.

I wasn't trying to compare the two approaches, I asked about the absolute security of the unsigned "prefix length" announcement. Even if you do compare them, there's a very big difference between them: the "prefix length" announcement is insecure by design, while the signed PrefixAnnouncement can potentially be secure.

So, maybe you should figure out the whole design of self-learning, including verification, before starting with the implementation... just saying...

According to the call on Jan 24, we are implementing self-learning for the current version of NFD (with on major changes). Thus, it is more adaptive to define the prefix announcement as a signed Interest, so that RIB can accept and recognize.

According to the call on Jan 24, we are implementing self-learning for the current version of NFD (with on major changes).

Yes.

Thus, it is more adaptive to define the prefix announcement as a signed Interest, so that RIB can accept and recognize.

This is NOT what the conference call decided. The decision was to keep Prefix Announcement format unchanged (Data encapsulated in PrefixAnnouncement TLV), and perform conversion from command Interest to the Data in the NFD nearest the producer.

Junxiao Shi wrote:

This is NOT what the conference call decided. The decision was to keep Prefix Announcement format unchanged (Data encapsulated in PrefixAnnouncement TLV), and perform conversion from command Interest to the Data in the NFD nearest the producer.

We decided to use the second option in note-31. If doing a conversion from command Interest to Data, the Data has to be converted to command Interest again when updating FIB. To be adaptive to the current RIB, making prefix announcement a command Interest is more efficient than a Data.

I discussed with Beichuan again. Here is the conclusion: the idea of directly sending PA to RIB (with the extension to recognize and validate PA) saves efforts, but making the design of RIB less clean. Thus, it is better to use a different thread to validate PA for self-learning, and to send control command to RIB separately.

the idea of directly sending PA to RIB (with the extension to recognize and validate PA) saves efforts, but making the design of RIB less clean.

It does not make RIB “less clean”. Prefix announcements are to be adopted as the primary way of indicating a prefix registrations, which RIB should support. rib/register command Interest is to become a thing of the past.

it is better to use a different thread to validate PA for self-learning, and to send control command to RIB separately.

Threading and logic separation are independent.

Alex suggested utilize existing structure (Data) as PA. I just realized that even only to change the TLV-Type from Data to PA requires related changes in the security module, such as signing PA, because PA is a different class with different encoding methods from Data class.

Well, you still need to wrap the Data block in a PrefixAnnouncement TLV. I think that was the idea. But honestly, we've gone back and forth so many times on every design detail of self-learning that I'm not even sure what the final decision was...

And the NDNLPv2 spec (as of r28) says something else entirely...

I've updated the NDNLPv2 spec. Wrapping data into a PA TLV block is a better idea.

There’s no such thing as “DATA-VALUE”.

A significant protocol problem is: Data immutability principle requires each Data to carry a unique name. However, the Data name contained in PA is directly used as the “announced prefix”. As a result, if an announcer ever needs to generate a new announcement (eg. when it wants to swap to a new signing key), it would be creating a new Data with the same name but different signature. This violates Data immutability principle.

Junxiao Shi wrote:

A significant protocol problem is: Data immutability principle requires each Data to carry a unique name. However, the Data name contained in PA is directly used as the “announced prefix”. As a result, if an announcer ever needs to generate a new announcement (eg. when it wants to swap to a new signing key), it would be creating a new Data with the same name but different signature. This violates Data immutability principle.

The Data wrapped in the PA is just for announcement purpose. It is not "real" Data to satify any Interest. We just utilize its code to reduce unnecessary work.

The Data wrapped in the PA is just for announcement purpose. It is not "real" Data to satify any Interest. We just utilize its code to reduce unnecessary work.

What prevents a malicious node from taking the Data enclosed in my PA to satisfy an Interest with my announced prefix and CanBePrefix=true? It needs to have some indication that the Data is a PA and not a regular blob, for example "MetaInfo.ContentType=PA".

NDNLPv2 rev31 still contains text about “signed Interest” that is completely wrong.

Also, it’s necessary to require the announced name to be a prefix of the Data name. The announcement MUST be ignored otherwise.

Junxiao Shi wrote:

A significant protocol problem is: Data immutability principle requires each Data to carry a unique name. However, the Data name contained in PA is directly used as the “announced prefix”. As a result, if an announcer ever needs to generate a new announcement (eg. when it wants to swap to a new signing key), it would be creating a new Data with the same name but different signature. This violates Data immutability principle.

A different name should be generated for the Data within a new PA (e.g., appending a timestamps).

Junxiao Shi wrote:

Also, it’s necessary to require the announced name to be a prefix of the Data name. The announcement MUST be ignored otherwise.

The name should start with a prefix that indicates this is a prefix announcement, e.g., /self-learning/PA/<real-prefix>. This can prevent the attack you mentioned in note-47.

I agree with note-49. Both points shall be specified in the protocol.

I've updated NDNLPv2 according to note-49.

BTW, apart from editing wiki page from web editor, is there a git repo for edition?

/self-learning/PA/<prefix-to-be-registered>/<timestamp>

Why two fixed components at the beginning instead of one? Do you expect to have more things under /self-learning ?

How is <prefix-to-be-registered> encoded?

Davide Pesavento wrote:

/self-learning/PA/<prefix-to-be-registered>/<timestamp>

Why two fixed components at the beginning instead of one? Do you expect to have more things under /self-learning ?

There may be more things in future, but one name component seems to work for the current protocol design.

How is <prefix-to-be-registered> encoded?

The next step is to construct a command Interest based on this announced name prefix, so is it easier if we put the whole name prefix into one name compnent (as string) and have a getter accordingly?

With the current code, putting <prefix-to-be-registered> into one name component seems to have more encoding work than keeping multiple name components.

is it easier if we put the whole name prefix into one name compnent (as string) and have a getter accordingly?

No. It should be multiple components. Otherwise you'll have trouble working with trust schema, because NDN regex cannot drill down inside a component.

NDNLPv2 rev35 still doesn’t define:

• whether announced name portion is one component or multiple components
• what’s the expected behavior if announced name is not a prefix of Data name (suggestion: SHOULD drop)

Junxiao Shi wrote:

NDNLPv2 rev35 still doesn’t define:

• whether announced name portion is one component or multiple components

rev35 has defined it, and I've polished the related text in NDNLPv2.

• what’s the expected behavior if announced name is not a prefix of Data name (suggestion: SHOULD drop)

In the current version, an NFD generates PA based on the matched FIB entry and attaches it to Data, so the announced name is a prefix of Data name. In future versions, a producer may generate PA, but as long as NFD decides which PA to be attached, the announced name should be a prefix of Data name. Thus, I don't think it is necessary to check this.

a producer may generate PA, but as long as NFD decides which PA to be attached, the announced name should be a prefix of Data name

Not checking the relation leads to an attack: a malicious upstream node can add a PA with an unrelated prefix (the PA was collected from the legit prefix owner earlier), and your node will install a FIB entry for the announced prefix toward the malicious upstream node.

Junxiao Shi wrote:

a producer may generate PA, but as long as NFD decides which PA to be attached, the announced name should be a prefix of Data name

Not checking the relation leads to an attack: a malicious upstream node can add a PA with an unrelated prefix (the PA was collected from the legit prefix owner earlier), and your node will install a FIB entry for the announced prefix toward the malicious upstream node.

Checking the relation does not prevent such attack. A malicous upstream can still attach a legit PA with a fake Data sharing the same prefix. My point is that if the decision of attaching PA to Data is controled by NFD, this attack can be avoided. (a network administrator can control that only legit NFDs are connected)

A malicous upstream can still attach a legit PA with a fake Data sharing the same prefix.

The self-learning dissertation chapter has a countermeasure to this: include a trust schema in the announcement itself. This isn’t part of this implementation.
But at least, require PA to match the Data prefix, and not permit just any PA.

Junxiao Shi wrote:

A malicous upstream can still attach a legit PA with a fake Data sharing the same prefix.

The self-learning dissertation chapter has a countermeasure to this: include a trust schema in the announcement itself. This isn’t part of this implementation.

Do you suggest that an NFD needs to verify both PA and Data to prevent such attack? If so, it involves more overhead than the point in note-59.

But at least, require PA to match the Data prefix, and not permit just any PA.

This is guaranteed with the point in note-59. No need to check it.

Do you suggest that an NFD needs to verify both PA and Data to prevent such attack?

Yes but overhead is less than “validating every packet”. See dissertation.

if the decision of attaching PA to Data is controled by NFD, this attack can be avoided

Nothing guarantees your upstream node is NFD and not some other software.

a network administrator can control that only legit NFDs are connected

“Legit NFD” is any node that possesses a certificate known by the network. It does not stop the node from getting infected by a malicious program. The network must protect itself from a misbehaving node. #1285 is the last line of defense and you should not depend on it to be the only line of defense.

what’s the expected behavior if announced name is not a prefix of Data name (suggestion: SHOULD drop)

I made a mistake on this suggestion. It shall be “SHOULD ignore the PA”.

Junxiao Shi wrote:

if the decision of attaching PA to Data is controled by NFD, this attack can be avoided

Nothing guarantees your upstream node is NFD and not some other software.

You can always control to whether to accept or drop data from whatever connects to your NFD.

a network administrator can control that only legit NFDs are connected

“Legit NFD” is any node that possesses a certificate known by the network. It does not stop the node from getting infected by a malicious program. The network must protect itself from a misbehaving node. #1285 is the last line of defense and you should not depend on it to be the only line of defense.

I've never mentioned to depend on it to be the only line of defense. My point is that the decision of attaching which PA to Data is should be controlled by legit NFD, and it is not necessary to check if the announced name is a prefix of Data name in the link service.

what’s the expected behavior if announced name is not a prefix of Data name (suggestion: SHOULD drop)

I made a mistake on this suggestion. It shall be “SHOULD ignore the PA”.

The forwarding strategy can do the check and ignore the PA.

Teng Liang wrote:

Junxiao Shi wrote:

“Legit NFD” is any node that possesses a certificate known by the network. It does not stop the node from getting infected by a malicious program. The network must protect itself from a misbehaving node. #1285 is the last line of defense and you should not depend on it to be the only line of defense.

I've never mentioned to depend on it to be the only line of defense. My point is that the decision of attaching which PA to Data is should be controlled by legit NFD, and it is not necessary to check if the announced name is a prefix of Data name in the link service.

Teng, this reasoning is flawed, you cannot assume that any other network entity behaves according to your wishes. That's like rule no. 0 of network security. You should instead treat every entity as malicious until proven otherwise. So I agree with Junxiao here that the PA--Data relation needs to be checked at some point.

Whether this check should be performed by the strategy or by the link service is another question, and I don't have any specific opinion on the matter. But it stands to reason that if a packet is invalid it should be dropped as soon as possible.

Davide Pesavento wrote:

Teng Liang wrote:

Junxiao Shi wrote:

“Legit NFD” is any node that possesses a certificate known by the network. It does not stop the node from getting infected by a malicious program. The network must protect itself from a misbehaving node. #1285 is the last line of defense and you should not depend on it to be the only line of defense.

I've never mentioned to depend on it to be the only line of defense. My point is that the decision of attaching which PA to Data is should be controlled by legit NFD, and it is not necessary to check if the announced name is a prefix of Data name in the link service.

Teng, this reasoning is flawed, you cannot assume that any other network entity behaves according to your wishes. That's like rule no. 0 of network security. You should instead treat every entity as malicious until proven otherwise. So I agree with Junxiao here that the PA--Data relation needs to be checked at some point.

Whether this check should be performed by the strategy or by the link service is another question, and I don't have any specific opinion on the matter. But it stands to reason that if a packet is invalid it should be dropped as soon as possible.

First, there is a way to control if connected NFDs are legit. Second, attaching which PA to Data should be controlled by NFD. With these points, it is still possible that attacks exist, and I am not objecting checking PA-Data relationship. I prefer to check it in the forwarding strategy, because fw uses PA to update FIB. If there is a must check in fw, it is not necessary to check it in the link service.

Teng Liang wrote:

First, there is a way to control if connected NFDs are legit.

How?

Davide Pesavento wrote:

Teng Liang wrote:

First, there is a way to control if connected NFDs are legit.

How?

Take the NDN testbed as an example, there should be some kind of authentication procedure before a node can connect to the testbed. I do agree that a node is always possible to be compromised.

Teng Liang wrote:

Davide Pesavento wrote:

Teng Liang wrote:

First, there is a way to control if connected NFDs are legit.

How?

Take the NDN testbed as an example, there should be some kind of authentication procedure before a node can connect to the testbed. I do agree that a node is always possible to be compromised.

#1285

Teng Liang wrote:

Davide Pesavento wrote:

Teng Liang wrote:

First, there is a way to control if connected NFDs are legit.

How?

Take the NDN testbed as an example, there should be some kind of authentication procedure before a node can connect to the testbed. I do agree that a node is always possible to be compromised.

Ok, so we agree that this mechanism cannot be relied on, even if it existed.

I agree with note-69. The PA-Data relationship must be checked in a forwarding strategy before updating FIB. They are also other checks, such as verifying PA and Data (not in this implementation, but in Junxiao's dissertation). I don't think putting such check in a link service is a good idea or necessary, given that it must be checked in a forwarding strategy.

The forwarding strategy can do the check and ignore the PA.

No, this needs to be checked in GenericLinkService on incoming path, and checked or asserted in GenericLinkService on outgoing path.

• Everything in NDNLPv2 has been implemented in GenericLinkService. Moving the check elsewhere creates an inconsistency.
• There could be more than one strategy that recognizes PAs. Having the check in GenericLinkService incoming path consolidates code. Having the check or assertion in GenericLinkService outgoing path protects against a misbehaving strategy.

Junxiao Shi wrote:

The forwarding strategy can do the check and ignore the PA.

No, this needs to be checked in GenericLinkService on incoming path, and checked or asserted in GenericLinkService on outgoing path.

Do you agree that this must be checked in forwarding strategy before updating FIB?

Do you agree that this must be checked in forwarding strategy before updating FIB?

No, the strategy does not need to check PA-Data name relation. However, it needs to verify PA is trusted.

Junxiao Shi wrote:

The forwarding strategy can do the check and ignore the PA.

No, this needs to be checked in GenericLinkService on incoming path, and checked or asserted in GenericLinkService on outgoing path.

• Everything in NDNLPv2 has been implemented in GenericLinkService. Moving the check elsewhere creates an inconsistency.

I don't think checking PA-Data should be part of NDNLPv2.

• There could be more than one strategy that recognizes PAs. Having the check in GenericLinkService incoming path consolidates code. Having the check or assertion in GenericLinkService outgoing path protects against a misbehaving strategy.

You have no idea how other strategy defines the PA-Data relationship.

• Everything in NDNLPv2 has been implemented in GenericLinkService. Moving the check elsewhere creates an inconsistency.

I don't think checking PA-Data should be part of NDNLPv2.

NDNLPv2 rev39 says:

the announced name in this field MUST be a prefix of the Data name. If the announced name is not a prefix of the Data name, this field SHOULD be ignored.

This is the only check required in GenericLinkService on both incoming path and outgoing path.

Signature verification should be placed elsewhere.

What if another forwarding strategy does not have this limitation (i.e., the announced name in PA is a prefix of Data)? This check only belongs to self-learning, so it is improper to be placed in link service.

What if another forwarding strategy does not have this limitation

This limitation is imposed by NDNLPv2 protocol as it appears in rev40, not by forwarding scheme.

Junxiao Shi wrote:

What if another forwarding strategy does not have this limitation

This limitation is imposed by NDNLPv2 protocol as it appears in rev40, not by forwarding scheme.

This limitation does not sound reasonable, so it should be removed from NDNLPv2. Keep the check in forwarding strategy.

Junxiao Shi wrote:

Do you agree that this must be checked in forwarding strategy before updating FIB?

No, the strategy does not need to check PA-Data name relation. However, it needs to verify PA is trusted.

The strategy MUST check* PA-Data name relation, since it cannot depend on the checking out of its control (other part is always possible to be compromized).

In addition, this rule of PA-Data name relation is defined by self-learning, and other strategy may have different PA-Data relationship. Thus the checking should be in the forwarding strategy, instead of link service.

Junxiao Shi wrote:

What if another forwarding strategy does not have this limitation

This limitation is imposed by NDNLPv2 protocol as it appears in rev40, not by forwarding scheme.

NDNLPv2 in rev41 does not have this limitation. Let's move forward.

Teng Liang wrote:

The strategy MUST check* PA-Data name relation, since it cannot depend on the checking out of its control (other part is always possible to be compromized).

Either the whole forwarder is compromised or none of it is. A threat model in which only a part of the forwarder is malicious would be pretty odd.

In addition, this rule of PA-Data name relation is defined by self-learning, and other strategy may have different PA-Data relationship.

Well, PrefixAnnouncement itself is defined by (and specific to) self-learning, so I'm not sure what "other strategy" you're talking about. There are no other strategies dealing with PA.

Davide Pesavento wrote:

Teng Liang wrote:

The strategy MUST check* PA-Data name relation, since it cannot depend on the checking out of its control (other part is always possible to be compromized).

Either the whole forwarder is compromised or none of it is. A threat model in which only a part of the forwarder is malicious would be pretty odd.

(1) Yes. The clearer statement would be that forwarding strategy is a better module to do the PA-Data name relation check than link service, because this check is one of the checks to verify if a PA should be used to update FIB, and all the checks should be conducted in the same place.

In addition, this rule of PA-Data name relation is defined by self-learning, and other strategy may have different PA-Data relationship.

Well, PrefixAnnouncement itself is defined by (and specific to) self-learning, so I'm not sure what "other strategy" you're talking about. There are no other strategies dealing with PA.

(2) Checking PA-Data name relation in link service has a broader effect than that in a strategy, and I don't know how strong this checking is. Based on (1), it is not necessary to do this check in link service, so I don't want to put a limitation in link service. There may be strategies in future that use PA.

Junxiao Shi wrote:

• Delete the ndn::lp::PrefixAnnouncement type.
• Change anything that uses ndn::lp::PrefixAnnouncement to use ndn::PrefixAnnouncement instead.>

code tp: https://gerrit.named-data.net/#/c/NFD/+/4914/

• Change self-learning route origin to "prefix announcement".

code tp: https://gerrit.named-data.net/#/c/ndn-cxx/+/4934/
doc tp: RibMgmt rev29

• Add equality comparison operator and stream insertion operator for ndn::PrefixAnnouncement type (refs #4650 for this one).

Teng Liang wrote:

Junxiao Shi wrote:

• Delete the ndn::lp::PrefixAnnouncement type.
• Change anything that uses ndn::lp::PrefixAnnouncement to use ndn::PrefixAnnouncement instead.>

code tp: https://gerrit.named-data.net/#/c/NFD/+/4914/

Wrong link?

Davide Pesavento wrote:

Teng Liang wrote:

Junxiao Shi wrote:

• Delete the ndn::lp::PrefixAnnouncement type.
• Change anything that uses ndn::lp::PrefixAnnouncement to use ndn::PrefixAnnouncement instead.>

code tp: https://gerrit.named-data.net/#/c/NFD/+/4914/

Wrong link?

Right, it should be https://gerrit.named-data.net/#/c/ndn-cxx/+/4932/.