[Ndn-interest] Data comes from another face?
christian.tschudin at unibas.ch
christian.tschudin at unibas.ch
Wed Jun 10 00:53:03 PDT 2015
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
> > >
> >
> >
>
>
>
More information about the Ndn-interest
mailing list