[Ndn-interest] Data comes from another face?

Ignacio.Solis at parc.com Ignacio.Solis at parc.com
Tue Jun 9 21:17:34 PDT 2015


On 6/9/15, 5:54 AM, "Muhammad Hosain Abdollahi Sabet"
<M.AbdollahiSabet at Mail.sbu.ac.ir> wrote:
>>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.
>
>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 I understand correctly, what you¹re doing is exploring with the
interests.  So the interests are doing some flooding, but the data is not.
 The data is coming back on an interface you sent the interest on.

BTW, I don¹t recommend this (flooding interests) without some more
advanced protocol on top.  Specially if you plan on modifying the FIB
based on there returned data object.   Unless you have some security
association to that requester/producer/name you may be asking for a
trivial attack on the network.


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

Like Marc mentioned, without some trust mechanism any node will be able to
black hole traffic and prefixes.  To make matters worse, if you¹re
flooding, any node will be able to see the interest traffic and carry out
the attack.

So, you¹re going to need to add some security semantics to your protocol.
I would guess that it¹s probably easier to use an on-demand routing
protocol (and secure that) than to use the interests to do the discovery
with security.

Nacho



>-----Original Message-----
>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.
>
>Marc
>
>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.
>>
>> 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
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>_______________________________________________
>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