[Ndn-interest] Data comes from another face?
Muhammad Hosain Abdollahi Sabet
M.AbdollahiSabet at mail.sbu.ac.ir
Tue Jun 9 05:54:41 PDT 2015
>Can you describe what you have in mind? Im unclear what you mean by self-learning path features with respect to the data objects. I can come up with protocols in my mind but they change the behavior of NDN/CCN drastically.
Suppose a consumer asks for a piece of data which is in a small/medium-scale access networks. In case A, at first due to not having FIBs built or not having record for a prefix, routers don't know where to forward the interest and do restricted flooding to find the data(and the corresponding prefix). After producer discovery, FIB record for the prefix will be made. Case B is when producer moves. So again the flooding will occur(maybe only for the first interest) to find the producer's new location and update FIB record. Actually it is more a like secondary forwarding strategy. In both cases, there is no need for sending data objects in broadcast or multicast. Case A is similar to Junxiao's presentation in NDNComm 2014 which I hadn't seen it before opening the topic.
>If you worry about compromised nodes or mis-behaving nodes, then accepting a Data object from an unexpected previous hop is a good way to allow those nodes to black-hole certain names, as those nodes could simply start sending bogus responses for common names.
You are right. My assumption is that in mobile producer case which consumer is looking for an actual node, names are not common so the risk is not high.
From: Ndn-interest on behalf of Marc.Mosko at parc.com
Sent: Tue 6/9/2015 3:23 PM
To: oran at cisco.com
Cc: Ignacio.Solis at parc.com; ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] Data comes from another face?
The ccnx 1.0 approach has been that neighbors operate like adjacencies plus broadcast interfaces so one could send a packet to a group, multicast, or broadcast address. In general, sending an Interest to a broadcast interface is not a great idea, I think, without some other protocols around it to prevent implosion. Group, multicast, and broadcast are useful for advertisements and discovery.
We currently have some automatic learning of these adjacencies but without a management protocol of security. I agree, we need a secure link management protocol and we have been discussing this internally for some time. We will bring this up with the community very soon.
In regards to the original poster's question about self-learning path discovery, how is that different than an on-demand routing protocol? There are also several questions one should answer, such as: is the network secure (i.e. at the physical or link level) or do you need to worry about compromised nodes or mis-behaving nodes? If you worry about compromised nodes or mis-behaving nodes, then accepting a Data object from an unexpected previous hop is a good way to allow those nodes to black-hole certain names, as those nodes could simply start sending bogus responses for common names which would then result in the end-device having to fail a signature validation and re-request the data with an exclusion or a name nonce.
On Jun 8, 2015, at 7:53 PM, Dave Oran (oran) <oran at cisco.com> wrote:
> Naive question:
> Are faces like L2 interfaces, or like routing adjacencies?
> If the former, all the kinds of weirdnesses regarding unsolicited data and non-transitivity show up.
> If the latter, you need an adjacency initialization and maintenance protocol (which all routing protocols running on multi-access links have), but you avoid all the messiness pointed out in this thread.
> My recommendation is that faces behave as adjacencies, not interfaces and that we adopt or design a good adjacency management protocol ASAP.
>> On Jun 8, 2015, at 2:45 PM, Ignacio.Solis at parc.com wrote:
>> On 6/8/15, 11:11 AM, "Muhammad Hosain Abdollahi Sabet" <M.AbdollahiSabet at mail.sbu.ac.ir> wrote:
>>> Actually I'm looking for a chances to have self-learning path feature, which implies - I guess - receiving data packets on faces which are not the same faces the interest has been forwarded to, or in better words the faces which is not in the corresponding FIB entry.
>> Can you describe what you have in mind? I'm unclear what you mean by self-learning path features with respect to the data objects. I can come up with protocols in my mind but they change the behavior of NDN/CCN drastically.
>>> I'm not quite aware of those security risks you are talking about, and I will be grateful If you could enlighten me a bit.
>>> The only point that is in my mind right now is that accepting such data packets will break fully symmetric subscriber-publisher approach.
>> Well, in a regular Interest->Data exchange allowing "off-path" responses basically means you can have nodes that shouldn't have authority in responding to traffic being able to generate responses. This is a waste of resources and a potential denial of service between otherwise cooperating nodes. A node off path can insert data in response to interests that will cause nodes to perform extra work (verifying hashes or signatures, triggering retransmissions, adding exclude filters, etc).
>> You can imagine this gets trickier on multi-access networks.
>>> -----Original Message-----
>>> From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com]
>>> Sent: Mon 6/8/2015 10:21 PM
>>> To: shijunxiao at email.arizona.edu
>>> Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu
>>> Subject: Re: [Ndn-interest] Data comes from another face?
>>> On 6/8/15, 10:15 AM, "Junxiao Shi" <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
>>> Sabet's original question is asking whether a Data packet could be received on a face where an Interest has not been forwarded to, under normal situations. The question is not about whether such Data packet should be accepted.
>>> Currently NFD forwarding would accept a Data packet as long as there is a PIT entry, without considering whether an Interest has been forwarded to the incoming face.
>>> This behavior is inherited from ccnd 0.7.2, and I know there's a security risk.
>>> Good thing we deprecated the old ccnd :-).
>>> I also suspect there would forwarding problems where transmissions on a multi-access link cannot reach every node.
>>> But I'm unfamiliar with those links, so I can't say exactly what problem could occur.
>>> Assume a network of: A--B--C--D where nodes can only hear neighbors. So: A can hear B but not C. B can hear both A+C. C can hear B+D, D can only hear C. A is a requester, D is a producer. A wants to get data located at D.
>>> Case 1 - Nodes don't forward interests over the interface they received them from.
>>> A sends and interest and B gets it. B needs to forward the interest, but won't do so over the same interface it arrived on. Protocol fails.
>>> Case 2 - Nodes forward interest over interface they received it on + nodes don't forward objects over same interface
>>> A sends an interest and B gets it. It forwards the interest. Any node that receives the interest will forward it, flooding the network. C gets the interest, D gets the interest. D responds. C gets the reply satisfying the PIT from the interface that requested it. It assumes somebody else answered. - Protocol fails.
>>> Case 2b - Nodes that receive duplicate interests (same nonce), send control message to prune
>>> Chaos ensues as networks larger than 3 start pruning each other. A sends to B. B sends to A+C. C sends to B+D.
>>> B sees same interest from C, sends a prune message to C. C removes pit state.
>>> Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry again. Protocol fails.
>>> Case 2b.2 - If there is no hold time on the PIT entry, it may get created again as the interest is still being flooded. Network will continuously prune and flood, collapsing. - Network fails.
>>> Case 3 - Nodes forward interest over interface they received it on + nodes forward objects over same interface
>>> Same as Case 2, interest is flooded on the network. and then the data is flooded on the network.
>>> I'm sure other cases exist.
>>> These errors don't occur if the link/interface/face has other properties. Like they can all hear each other (though there may are other issues in this scenario alone), there is an underlying protocol (like MAC level unicast), next-hops are used instead of interfaces/links/faces, etc.
>>> Again, maybe there are NDN features I'm not aware of or forgot. But either way, it's a good discussion to have. And maybe you can clarify how NDN handles these cases.
>>> On Mon, Jun 8, 2015 at 9:55 AM, <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>> wrote:
>>> Hi folks.
>>> I wanted to bring up a couple of important points to this discussion that have not been mentioned. Maybe people have already assimilated them so they think they're obvious, but just in case:
>>> 1- A node should not accept data packets over links/interfaces/faces over which it did not forward an interest. This is a security risk.
>>> 2- NDN may have issues over multiple access links/interfaces/faces where not all nodes can hear each other (non-infrastructure WiFi).
>>> Both of these are true in the basic case. It's possible that with extra design, protocols or developments that I'm unaware of these can be mitigated/solved.
>>> Nacho (Ignacio) Solis
>>> Protocol Architect
>>> Principal Scientist
>>> Palo Alto Research Center (PARC)
>>> Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest