[ndnSIM] Interest Flooding Attack Strategies
alexander.afanasyev at ucla.edu
Mon Jun 17 17:32:55 PDT 2013
I would say that for simulation purposes, you can simply use "Signature" fields that is currently available. Again, this is only for simulation purposes, but assuming that signature "1" (just number one) represents right key locator and genuine packet, while signature "2" (just number 2) represents wrong key locator and/or modified public key digest, would capture all the "wrongdoings" by the malicious nodes without incurring unnecessary overhead. Do you think it can work in your case?
On Jun 17, 2013, at 5:02 PM, Amin Karami <amin at ac.upc.edu> wrote:
> Hi Alex,
> I am going to manipulate some fields of data packets in side of the publisher to construct unsatisfiable interest packets deliberately, such as:
> 1- 'publisherpublickeydigest': By changing the public key value of the packet.
> If there is no 'publisherpublickeydigest' field in current ndnSIM, Is there another way to change deliberately the data packet?
> 2- 'KeyLocator': change deliberately data packet's verification key (e.g., make fake/spurious key).
> On 06/18/2013 01:34 ق.ظ, Alex Afanasyev wrote:
>> Hi Amin,
>> 1. I would say that such a case should be considered as an attack, though whether it is "flooding" or not would depend on the consumer data fetching strategy. For example, if you use ConsumerWindow, then if it cannot fetch data, it will reduce it's window to one and would do re-tries very infrequently (at max RTO periods). In other case, if you use ConsumerCbr with high frequency, then this almost definitely would be an attack. Note that ConsumerCbr will do re-requests for the same data, which is a little bit different from "real" flooding attack, where requester will send unique requests all the time (like this DumbRequester example: http://ndnsim.net/applications.html#dumb-requester)
>> 2. There is no publisherpublickeydigest in ndnSIM currently, but I'm not entirely sure about your question. What exactly do you want to achieve?
>> 3. Again, ndnSIM doesn't yet support Exclude filter, but I'm working on it and it should be there relatively soon. However, exclude filter doesn't work this way, it allows you to exclude a specific name component(s) that goes after whatever you requested. For example:
>> you send interest for /ndn/prefix/bla with exclude filter x1,x2,x3, meaning that you want some data packet that has prefix /ndn/prefix/bla but does not contain prefix
>> 3.5 Not sure what is your question about KeyLocator. What functionality you want from it? Since ndnSIM is a simulator, there is no (and I would say, there should not be) actual verification process and it can be implemented using flags (e.g., in Signature field), making assumptions about these flags.
>> On Jun 16, 2013, at 8:47 AM, Amin Karami <amin at ac.upc.edu> wrote:
>>> I want to run a scenario in ndnSIM with Interest Flooding Attack (IFA) purposes as non-existent contents requested. But i faced with some problems in ndnSIM as follows:
>>> 1- If we declare a consumer with predefined interest requesting parameters, but do not define any producer to satisfy consumer interest packets, can it be such a interest flooding attack?
>>> 2- Set the 'PublisherPublicKeyDigest' field to a random value. because there is no public key would match this value, So, interest packets will remain unsatisfied. How can we modify this parameter in ndnSIM for a specific node?
>>> 3- Set the interest 'Exclude' filter to exclude all existing content starting with e.g., /ndn/prefix. how is it possible in ndnSIM for a specific node? How about 'KeyLocator' field?
>>> Thank you in advance.
More information about the ndnSIM