[Ndn-interest] Selector Protocol over exact matching

[Lan Wang (lanwang)]

On Sep 25, 2014, at 6:17 PM, <Ignacio.Solis at parc.com>
 wrote:

> On 9/25/14, 10:35 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:
> 
>> In NDN, if a router wants to check the signature, then it can check.  If
>> it wants to skip the checking, that's fine too.  If the design doesn't
>> allow the router to verify the signature, then that's a problem.  In the
>> above description, the cache signs a data packet with a name owned by
>> someone else, it seems problematic for a design to advocate this.
> 
> Routers that support the Selector Protocol could check signatures.

The question here is whether the cache should be allowed to generate a data packet with a name belonging to someone else.  There is no clear trust model here and checking signature without a clear idea of what key is allowed to sign the data does not seem to be meaningful to me (or if any key is allowed to sign a piece of data, then there's no need for generating the signature and signature checking).
> 
>> 
>> One difference is that here the returned data can satisfy only that
>> interest.  In the original selector design, the returned data can satisfy
>> other Interests with the same name but different selectors (e.g., > 50).
> 
> Interests with the same selector would be exact matched throughout the
> network at any node.
> 
> Interests with different selectors would not match on all routers, but
> they would match just fine on routers that supported the Selector Protocol.
> 
> Basically, everything you want works on routers that support the Selector
> Protocol, but routers that don¹t want to support it, don¹t have to.
> 

It seems that the behavior of the routers that support the hash-based selectors would be very complicated.  Suppose it gets a real data packet (/name/100) from its upstream to satisfy the Interest (/name/100).  In addition to forwarding the data, it needs to check all other Interests with the /name prefix but with some other component following /name, because they might be hash based Interests.  Some of them may not be hash based Interests, just Interests like /name/99, but it's hard to tell which is which.  So you have to check all of them.  If any of them is such a hash-based selector Interest, you check the selector and if it satisfies the selector, you need to encapsulate the real data packet and sign it to send this to downstream (in addition to forwarding the real data packet.  

Another problem is what if the name of the real data /name/xxx collides with the Interest with the hash-based selector (the hash is also xxx).  

Nevertheless,  my main concern is the first point about the cache generating the data packet with others' name prefixes.

Lan
> 
> Nacho
> 
> 
> 
>>> 
>>> 
>>> 
>>> --
>>> Nacho (Ignacio) Solis
>>> Protocol Architect
>>> Principal Scientist
>>> Palo Alto Research Center (PARC)
>>> +1(650)812-4458
>>> 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
>