[Ndn-interest] Securing Data packet.

[David R. Oran]

On 3 Jul 2019, at 12:33, Andriana Ioannou wrote:

> Hi David,
>
> Many thanks for your reply. I actually have two use-case scenarios 
> which
> modify Data packets, both somewhat related to caching.
>
> In the first scenario, I have a number of fields in the Data packet 
> that
> defines how many hops the corresponding Interest packet, that 
> triggered
> this Data packet, did traverse, as well as the number of hops that the 
> Data
> packet traversed.
There’s already been a proposal to add a “hops traversed” field to 
data packets (outside the security envelope). This turns out to be 
fairly trivial, as the hop limit field in Interests can be re-purposed 
for this in Data packets. (Aside: I think I proposed this as far back as 
2014). CCNx I think may already include it (I can check if you want); 
NDN does not currently because NDN only recently added hop limits to 
Interests to fix the long-standing bug that nonces alone don’t 
suppress loops if you allow Interest retransmissions by forwarders.

> This is used by the downstream routers to make caching
> decisions. So, at each hop one of the fields in that Data packet is
> expected to change, i.e. increased by one. This information basically 
> tells
> a router how far away a content source is and whether it would be
> beneficial to cache the content or not.
Distance from publisher may or may not be the best metric, but it is of 
course worth evaluating under what topologies and access patterns it 
helps, so your research here could be quite valuable. For amore 
comprehensive look at what metrics one might use - especially in terms 
of density and fan-out (which can possibly mirror a centrality metric), 
you might find the ideas in

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=8,874,845.PN.&OS=PN/8,874,845&RS=PN/8,874,845

worth looking at.

Aside: don’t worry about the fact that this is patented, as the patent 
holder (Cisco) has made its ICN-related patents freely available to 
people working on CCN or NDN).

> The security implication is that
> someone that "seats" between any two routers may alter this packet 
> field,
> and "enforce" the rest of the routers downstream to make wrong caching
> decisions and ultimate degrade the performance of the network.
>
Well, if it’s a MITM, the hop-by-hop protection you would get from 
link-level (or tunnel) encryption can foil this. If the someone is an 
on-path NDN forwarder, then of course all bets are off. Any on-path NDN 
forwarder can do anything it likes - drop packets, inject packets, 
modify packets, etc. Messing with caching is just one of the 
vulnerabilities, and frankly not as bad as a cache poisoning attack 
which is trivial for an on-path router to mount.

> In the second scenario, I as a border router, i.e. an edge router that
> propagates traffic externally to the Internet infrastructure, keep 
> track of
> the traffic that is propagated. My goal is to reduce the external 
> traffic
> to avoid extra costs. So, if I record too much traffic for some 
> content I
> modify one of the return Data packets to notify a consumer to act as a
> temporary content source; meaning that when the consumer gets the
> corresponding Data packet it advertises that it has a copy within the 
> local
> network.
This sounds like routing… not caching. I would think instead of 
modifying data packets you’d announce the prefix for which you are 
caching lots of stuff via the routing protocol.

> This may be used by subsequent requests to be satisfied locally
> within the network. Again, the security implication is that someone 
> could
> modify this field of the Data packet, making different consumers to
> advertise their content and prevent the ones that should advertise 
> them to
> do so.
Again, if the someone is an on-path router, all bets are off and 
achieving caching optimizations by putting stuff in data packets (like 
the above-mentioned patent) doesn’t change the equation in any 
significant way.

However, like you I’m not a security expert, so someone with a 
stronger security background might choose to differ.

Best,
DaveO.

>
> I hope that clarifies a bit my issues!
> Kind regards,
> Andriana.
>
> On Wed, 3 Jul 2019 at 19:11, David R. Oran <daveoran at orandom.net> 
> wrote:
>
>> On 3 Jul 2019, at 10:45, Andriana Ioannou wrote:
>>
>>> Dear all,
>>>
>>> In my current research I have altered the Data packets to include 
>>> some
>>> information that will allow the routers on delivery paths to make
>>> better
>>> caching decisions. This information may be updated during delivery
>>> from the
>>> routers downstream.
>>>
>> It would be useful if you could elaborate a bit on what you’re 
>> trying
>> to accomplish and what information might be added to the packet 
>> (outside
>> the signatures’s security envelope since you say you want this to 
>> be
>> modified hop-by-hop).
>>
>>> I have been looking on the security implications for this, and so 
>>> far
>>> I
>>> understand that the community is mostly focused on the content
>>> contained in
>>> a Data packet, and the related fields, e.g. name and key locator,
>>> rather
>>> than securing the whole Data packet.
>> Well, since forwarding is stateful in NDN, you likely need to not 
>> only
>> keep mutable fields in the clear so the routers can see them, eschew
>> end-to-end integrity so you can modify them. It would be helpful if 
>> you
>> could articulate what threats you hope to address by “securing” 
>> the
>> entire data packet. Misbehavior by on-path routers? (note that 
>> packets
>> can be protected on links via hop-by-hop encryption, so any
>> vulnerabilities are ones introduced by on-path routers).
>>
>>> My guess is that this would be an
>>> important overhead/cost since each router involved in the process 
>>> will
>>> have
>>> to decrypt each incoming Data packet to ensure its valid.
>>>
>> Well, you can ensure against modification with just integrity (e.g. 
>> with
>> SHA) so there must be some confidentiality threat you want to foil by
>> encryption.
>>
>>> The only option I could think of would be to "enforce" the publisher
>>> to
>>> sign those fields of the Data packet, too. Yet, this would mean that
>>> the
>>> signature would not refer only to the content requested by the
>>> consumer,
>>> which I guess is fundamentally wrong since you end up delivering
>>> "garbage"
>>> to your consumers...
>>>
>> I’m not sure I follow this. There’s a fundamental disconnect 
>> between
>> end-to-end integrity via signatures and the ability to modify packets 
>> as
>> they traverse the network.
>>
>>> I would appreciate if you could argue on this, since my security
>>> background
>>> is a bit limited. I would be happy to be pointed out on some related
>>> literature too - if available.
>>>
>> It’s hard to know what to point you to without knowing in more 
>> detail
>> what you’re trying to accomplish.
>>
>>> Kind regards,
>>> Andriana.
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>> DaveO
>>



DaveO