[Ndn-interest] Selector Protocol over exact matching

Marc.Mosko at parc.com Marc.Mosko at parc.com
Thu Sep 25 03:30:26 PDT 2014


In the ccnx 1.0 packet format:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+---------------+---------------+
   |    Version    |  PacketType   |         PayloadLength         |
   +---------------+---------------+---------------+---------------+
   |  HopLimit (I)*|  reserved     |         HeaderLength          |
   +---------------+---------------+---------------+---------------+
   / Optional header TLVs                                          /
   +---------------+---------------+---------------+---------------+
   | CCNx Message TLV                                              /
   +---------------+---------------+---------------+---------------+
   / Optional CCNx ValidationAlgorithm TLV                         /
   +---------------+---------------+---------------+---------------+
   / Optional CCNx ValidationPayload TLV (ValidationAlg required)  /
   +---------------+---------------+---------------+---------------+

which shares with NDN the property that the validation is put around the core message, things like the KeyId are particular to the authentication, not necessarily integral to the name.

For example, a sensor could publish /parc/building33/pod22/room2270/t=20140925T110203 with an HMAC signature identified by a key exchange protocol identifier “33790” with its IoT gateway.  The IoT gateway might then strip away the HMAC validator and sign it with an RSA signature with a new validator with a standard KeyId.

Therefore, I would not want to be including things like KeyId in the name.  though of course the IoT gateway could re-name the measurement…

Our approach was that every function applied in the fast path should have a distinguished field, thus the KeyIdRestriction and ContentObjectHashRestriction are distinguished TLV fields, not buried in the name.  Things that must execute in the forwarding for correct operation need to be governed by the “version” of the packet header.  We would say that the correct processing of these two restrictions is necessary for correct operation.

Optional or proprietary forwarding hints could be encoded in the name, in the “optional header tlvs” or in vendor-specific (assigned) TLVs in the message body.  They would be skipped by systems that don’t know about them.

Marc

On Sep 25, 2014, at 12:04 PM, christian.tschudin at unibas.ch wrote:

> On Thu, 25 Sep 2014, Ignacio.Solis at parc.com wrote:
> 
>> On 9/25/14, 9:17 AM, "Marc.Mosko at parc.com" <Marc.Mosko at parc.com> wrote:
>>> In the CCNx 1.0 spec, one could also encode this a different way.  One
>>> could use a name like ³/mail/inbox/selector_matching/<hash of payload>²
>>> and in the payload include "exclude_before=(t=version, l=2, v=279) &
>>> sort=right².
> 
> this discussion turns into a thread on how to encode function calls. It would be nice if CCNx 1.0 would go ahead and offer a general function call schema and apply it itself.
> 
> For example, the CCNx 1.0 spec still has a special field "contentObjectHash" just for invoking the compare-the-message-digest function, same for "keyIdRestriction". I would like to see them handled with a common function call schema and to deal with them at the same level as selectors as you propose, namely as a request to the "network as a whole" without mandating that each node has to satisfy it.
> 
> Along the line of Marc's notation:
> 
> "/mail/inbox/20140925/<hash of payload>"
> and in the payload include "matchObjectHash(h=abcd) & matchKeyId(i=xxx)"
> 
> Of course, in PARC's network each node will honor such function calls; but other networks could opt to guarantee that semantics edge-to-edge, yet remain interopable (=catenet-friendly).
> 
> This links to your main point, namely which functions have to be built-in at each forwarder (as opposed to network-as-a-whole). I agree with you that we should examine the requirements for letting people like us (using selectors or named-functions) use your substrate. Here is one more wish, beyond the generic function-call packet format above:
> 
> - Distinguish the name on which to route from the name of the object.
> 
>  This can be implemented by having a mandatory pointer field
>  "nameUnderRoute" in the fixed header that points to either the
>  name in the interest, or a field in the optional headers section
>  (inserted by some forwarder).
> 
>  The reason for this is that an object's name does not necessarily
>  reflect where the request is best satisfied - it could be a
>  function's name. For example, there could be a few nodes *in* your
>  network knowing how to handle selectors, so you might want to
>  route to them. The network will have to figure this out.
> 
>  Another use case are virtualization tricks like label stacks.
> 
> best, christian
> 
> 
>> 
>> 
>> I want to highlight this.
>> 
>> There is a role that selectors can play in a network.  However, our
>> biggest issue with selectors is that they are mandated at the forwarder
>> level.  This means that every node must support selectors.
>> 
>> We want to make sure that the core protocol is simple and efficient.
>> Exact matching gives us that.  If you¹re interested in selector matching
>> and searching, then create that protocol over exact matching.
>> 
>> Marc just described a simple ³Selector Protocol", basically:
>> - Encode selectors (or any query you want) in the interest payload.
>> - Add a name segment to indicate that this is a selector based query
>> - Add a name segment to uniquely identify the query (a hash of the payload
>> for example)
>> 
>> Example:
>> name    = /mail/inbox/list/selector_matching/<hash of interest payload>
>> 
>> payload = version > 100
>> 
>> Topology:
>> 
>> A ‹‹ B ‹‹ C
>> 
>> A and C run the Selector Protocol
>> B does not run the Selector Protocol
>> 
>> Now:
>> - Any node that does not understand the Selector Protocol (B) forwards
>> normally and does exact matching.
>> - Any node that understands the Selector Protocol (C) can parse the
>> payload to find a match.
>> 
>> If no match is found, forward the interest.
>> If a match is found, create a reply.
>> 
>> The reply can contain 2 types of data:
>> - Structured data with links to the actual content objects
>> - Encapsulated content objects
>> 
>> So, in our example, the Selector Protocol reply could be:
>> 
>> name = /mail/inbox/list/selector_matching/<hash of interest payload>
>> payload =
>> [  matching name = /mail/inbox/list/v101 ]
>> [  embedded object < name = /mail/inbox/list/v101, payload = list,
>> signature = mail server > ]
>> signature = responding cache
>> 
>> 
>> 
>> A few notes:
>> - Malicious nodes could inject false replies.  So, if C is malicious, it
>> can insert a reply linking to some random object or just return junk.
>> Well, this would be the case with regular selectors as well.  C could
>> reply with random crap or it could reply with a valid answer that is not
>> the optimal answer (so, for example, not the right-most child or
>> something).
>> This is something that we can¹t prevent.
>> 
>> In the case of CCN, our fast path does not check signatures, so you
>> wouldn¹t be able to check the signature of the reply no matter what.  I¹m
>> unsure if NDN is still advocating that every node checks signatures.  If
>> you are, then this approach might not work for you.
>> 
>> Nodes that DO understand the Selector Protocol can check the signature of
>> the encapsulated reply (if they wanted to).
>> Nodes that DO understand the Selector Protocol can unpack the reply, and
>> add the corresponding object to their cache, effectively enabling them to
>> answer other Selector Protocol queries.
>> 
>> - The reply from the Selector Protocol enabled node (C), could:
>> ‹  include a list of all valid answers
>> ‹  embed no objects
>> ‹  embed more than 1 object
>> ‹  process complex queries, regex, etc.
>> 
>> The Selector Protocol could also:
>> - include a method for authentication
>> - include a cursor or some other state between queries
>> 
>> 
>> I think this sort of protocol gives you everything you want while still
>> maintaining an exact match protocol as the core protocol.
>> 
>> 
>> What is this protocol missing to satisfy your needs?
>> Can we create a protocol that will satisfy your needs on top of exact
>> matching?
>> 
>> 
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140925/85e66625/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2595 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140925/85e66625/attachment.bin>


More information about the Ndn-interest mailing list