[Ndn-interest] Data comes from another face?

Marc.Mosko at parc.com Marc.Mosko at parc.com
Wed Jun 10 02:08:27 PDT 2015


Christian,

CCN 0.x and CCN 1.0 and NDN could verify a cryptographic signature at every hop, but in practice do not due to performance overhead.  I do not believe this is a difference between ccnx and ndn.  If a consumer asked for content by name and public key digest and each response (or at least a sufficient percentage) carried the public key [1], then each hop could verify it to within the collision probability of the sha256 digest of the public key.

Likewise, if a consumer requests content by name + data hash, then each hop should verify the hash at each hop.  We believe this is the best way to get trusted delivery.  However, if one is doing path discovery (as the original poster said), then I don’t think one can do that with data hash names.  So, this option is not available to the OP’s question.

However, if the consumer is only using names or only using names + keyid requests, then in general there is a blackhole vulnerability because usually each hop is not verifying the cryptographic signature.  

I agree that saying “secure an on-demand protocol” is kicking the can down the road, however there has been a history of work in this area along with reputation algorithms and other ways to cross-check that routing information advertised by one node is consistent with advertisements from other nodes (to within collusion limits).

Marc

[1] there are many ways to get the public keys in to the network and they have lots of trade offs.

On Jun 10, 2015, at 8:53 AM, <christian.tschudin at unibas.ch> <christian.tschudin at unibas.ch> wrote:

> Hi Nacho,
> 
> this is basically a useful warning, but I think this is not true in general and fingerpointing in the wrong direction? A historically different perspective:
> 
> In the original concept of cryptographically bound name+content, the lookup operation is idempotent and it does not matter through which face content is flowing back because the forwarder can validate and ground the packet if validation fails.
> 
> Now CCNx1.0 has opted to move validation to the end points and then - sure - the attack angle shifts and acceptance rules have to be revised. In fact, on top of defining restrictions on what a router accepts, now you also have to trust the delivery chain: any malicious upstream node can do the blackholing and face bookkeeping acceptance rules alone will not solve this (new) problem. *)
> 
> Regarding over-generalizing the warning: CCNx1.0 still overlaps with that original vision and could go beyond your safety warning perimeter. Data that is requested with a ContentObjectHash restriction is safe to accept from any face because the router can validate locally. I'm not aware if CCNx1.0 does that optimization or not (well, this is the general uphill battle of closed source ...)
> 
> So I guess we have to look case-by-case, and for sure selectors and other non-idempotent operations like expiry-values, scope and hop limits are food for thought.
> 
> Best, christian
> 
> *) And linking this to the "adjacency thread" on the NDN interest list: I'm concerned that such adjacency protocols will re-introduced the secured circuits that the original CCN wanted to get rid of.
> 
> Dont misunderstand me: I think that adjacency protocols are a good thing to have - the question is how far they want to reach and how much they open the arena for gaming the free flow of validated content, the "data acceptance rules discussion" just being the prelude.
> 
> 
> On Mon, 8 Jun 2015, 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
>> Ignacio.Solis at parc.com
>> On 6/8/15, 9:22 AM, "Muhammad Hosain Abdollahi Sabet"
>> <M.AbdollahiSabet at mail.sbu.ac.ir> wrote:
>> 
>>      Junxiao,
>> 
>>      Thank you for responding.
>> 
>>      >?Infrastructure WiFi is different: at MAC layer, all
>>      communications go through the AP (access point).
>>      We could take advantage of this property, and install an NDN
>>      stack on the AP that aggregates Interests and caches Data.
>> 
>>      ?You mean we turn a L2 device (access point) into a wireless
>>      router?
>> 
>>       ?
>>      ?>?the AP treats the WiFi link as both a multi-access link where
>>      packets can be broadcast to all wireless clients, and one
>>      point-to-point link to each wireless link.
>> 
>>      Does that make any difference? An ap treat a link as a
>>      multiple-access or a point-to-point link. I mean in both cases,
>>      the ap does the same thing(transmit one copy of a packet). The
>>      only difference would be in L2 addressing?, right? Of course
>>      there could be difference if using omnidirectional or
>>      unidirectional antennas, which could be a big deal facing mobile
>>      nodes. But that's out of computer networking scope.
>> 
>>      Thanks,
>>      Sabet
>> 
>>      -----Original Message-----
>>      From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
>>      Sent: Thu 6/4/2015 2:19 AM
>>      To: Muhammad Hosain Abdollahi Sabet
>>      Cc: ndn-interest at lists.cs.ucla.edu
>>      Subject: RE: [Ndn-interest] Data comes from another face?
>> 
>>      Hi Sabet
>> 
>>      Ethernet repeater and UDP multicast group are two examples of
>>      multi-access
>>      links.
>> 
>>      Infrastructure WiFi is different: at MAC layer, all
>>      communications go
>>      through the AP (access point).
>>      We could take advantage of this property, and install an NDN
>>      stack on the
>>      AP that aggregates Interests and caches Data. Under this design,
>>      a wireless
>>      client treats the WiFi link as a point-to-point link to the AP,
>>      and the AP
>>      treats the WiFi link as both a multi-access link where packets
>>      can be
>>      broadcast to all wireless clients, and one point-to-point link
>>      to each
>>      wireless link.
>> 
>>      Yours, Junxiao
>>      On May 31, 2015 2:27 PM, "Muhammad Hosain Abdollahi Sabet" <
>>      M.AbdollahiSabet at mail.sbu.ac.ir> wrote:
>> 
>>      >  Junxiao,
>>      >
>>      > So in wired nets it would be good old BUS or ethernet HUB
>>      networks, which
>>      > is rare these days unless we face lack of switching devices.
>>      And in
>>      > wireless nets, generally all of them are multiple-access link,
>>      right?
>>      >
>>      > Actually It'very good to see you here by chance. Lately I've
>>      been thinking
>>      > on intelligent(self-learning) forwarding and I was counting
>>      different
>>      > situations which it would be useful for. Just a couple of
>>      hours ago I saw
>>      > your presentation about NDN in LANs at NDNComm and I was like
>>      :| "Again,
>>      > I've got here late!", though I had felt the need for such a
>>      self-learning
>>      > mechanism in producer mobility. I don't know if still there is
>>      a room to
>>      > contribute more in this. As far as I already saw, this NFD in
>>      addition to a
>>      > pointer to the chosen output face in PIT, which is available
>>      right now,
>>      > lacks some pointer to the chosen FIB entry itself. And of
>>      course some
>>      > measures are needed to check efficiency of self-learned chosen
>>      faces after
>>      > a while and see if another flooding is needed for choosing
>>      possible better
>>      > face.
>>      >
>>      > Thanks,
>>      > Sabet.
>>      >
>>      >
>>      > -----Original Message-----
>>      > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu
>>      > <shijunxiao at email.arizona.edu>]
>>      > Sent: Sun 5/24/2015 1:48 AM
>>      > To: Muhammad Hosain Abdollahi Sabet
>>      > Cc: ndn-interest at lists.cs.ucla.edu
>>      > Subject: Re: [Ndn-interest] Data comes from another face?
>>      >
>>      > Hi Sabet
>>      >
>>      > As I understand you question is:
>>      > In a network of NDN nodes where none of the nodes is using
>>      broadcast
>>      > strategy, if a node has not forwarded an Interest out of an
>>      interface, is
>>      > it possible for this node to receive a Data on this interface?
>>      >
>>      > The answer is YES.
>>      > Think about a multi-access link with 3 hosts P Q R.
>>      >
>>      >    1. Q sends an Interest. P and R receive this Interest,
>>      >    2. P replies with a Data. Q and R receive this Data.
>>      >
>>      > In this scenario, R has not forwarded an Interest to the
>>      multi-access link,
>>      > but receives a Data from the multi-access link.
>>      >
>>      > Yours, Junxiao
>>      >
>>      > On Wed, May 20, 2015 at 11:17 AM, Muhammad Hosain Abdollahi
>>      Sabet <
>>      > M.AbdollahiSabet at mail.sbu.ac.ir> wrote:
>>      >
>>      > >  Hi,
>>      > > We all know that data packets follow breadcrumbs which
>>      interest packets
>>      > > leave behind. And we expect to receive data packets from the
>>      same face
>>      > > which interests have already been forwarded to, according to
>>      > correspondent
>>      > > fib entries, right? So, when the second sentence won't
>>      happen? I mean a
>>      > > node receive a data packet matching a pit entry, from a face
>>      that the
>>      > > interest has not been forwarded to, according to the fib
>>      entry. If a node
>>      > > choose to broadcast for forwarding strategy, such a
>>      situation happens. I
>>      > > know that. But is there any other condition?
>>      > >
>>      > > Thanks,
>>      > > Sabet
>>      > >
>>      >
>>      >
> _______________________________________________
> 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