resource starvation attacks - Re: iqnets: opportunistic XYZ, e.g. "begin xmit"

[Zenaan Harkness]

> Step 2:
> 
>   Node A and middle node B, nego "headroom" links AB, and BN:
> 
>     - A requests of B to "reserve excess headroom for real time b/w W,
>       of intended duration ~T, beginning "asap".
> 
>     - B checks its current link undertakings (bulk, r/t, total b/w vs
>       b/w availability etc), and offers to A something like:
> 
>       - I can ACK your request not before 13 minutes, (presumably due
>         to current link contracts);
> 
>         I will hold open this offer for you, for 10 seconds, i.e. I
>         will not enter new link contracts before $NOW + 10s.


A consequential issue arising in relation to "network layer
contracts", is one or another resource starvation attack:

  - if our protocols are sufficiently weak (attackable), then

  - stalker nodes S1, S2 ... Sn can "gang up" against node B

  - e.g., nodes Ss may repeatedly (say in random round robin fashion)
    make a certain resource request of node B, in order to starve
    either or both of node B, and node B's friend nodes, from that
    resource

    If node B naievely/ eagerly ACKs such contract requests,
    without suitable mitigation protocols
    then both B and B's friend nodes, will be starved
    of that resource.


  "Unconstrained eager contract agreement,
   is a resource starvation attack exposure point."



Example resource starvation mitigation protocols:

  - headroom reservation,
    with the headroom available to preferred nodes only;

    watch out for information leakage here

  - local node and friend node preferencing;

  - time limiting contract ACKS, so that maximum latency "until next
    availability window" is reduced;

    but as usual, be very cautious about information leakage here


Depending on protocols, we may steer strongly or weakly to different
virtual network topologies, and the difference between these topos
must be considered at some point:

  - strongly preferenced/ maintained F2F links, vs

  - weak F2F preferencing

  - information leakage every time a resource is "repurposed",
    unless there are protocol mitigations (primarily randomization
    of one form or another)

  - so randomized shifting between friend and anon nodes may bode
    well for global network flexibility, whilst maintaining
    reasonable preferred node resource availability, whilst hiding
    actual usage of said resources by said preferred nodes

  - ultimately we are balancing between various, sometimes competing,
    sometimes complementary, goals:

    - privacy

    - anonymity

    - latency

    - resource usage
      (are we on average actually making use of offered resources)

    - efficiency
      (what are the overheads to deliver the resource)

    - connectivity
      (to whom (which nodes) is a resource available)

    - availability
      (when is a resource available)


By handling billions of nodes at core and not as an afterthought, we
may be able to achieve desirable combinations of the above
characteristics in relation to various resources.


Again, network resources include:

  - b/w (bandwidth)

  - b/w over duration

  - latency

  - latency over duration

  - data storage

  - data storage over duration

  - link count

  - link count over duration


Are we yet missing a basic "network level" resource?



PS: when we use the term "latency" as a noun referring to a resource,
we mean "desirable latency" which is usually low latency.