[Ndn-interest] Data comes from another face?

Dave Oran (oran) oran at cisco.com
Mon Jun 8 11:53:41 PDT 2015


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.

DaveO.

> 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.
> 
> Nacho
> 
> 
> 
>> -----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.
>> 
>> Nacho
>> 
>> 
>> 
>> 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
>> 
>> 
>> --
>> Nacho (Ignacio) Solis
>> Protocol Architect
>> Principal Scientist
>> Palo Alto Research Center (PARC)
>> +1(650)812-4458<tel:%2B1%28650%29812-4458>
>> Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>
>> 
>> 
>> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest





More information about the Ndn-interest mailing list