Prop. 168 updates after 12/3 review

i2p2www/spec/proposals/168-tunnel-bandwidth.rst

@@ -5,7 +5,7 @@ Tunnel Bandwidth Parameters
     :author: zzz
     :created: 2024-07-31
     :thread: http://zzz.i2p/topics/3652
-    :lastupdated: 2024-07-31
+    :lastupdated: 2024-12-09
     :status: Open
     :target: 0.9.65
 
@@ -29,7 +29,10 @@ used by all participating tunnels and the total bandwidth limit for participatin
 Requesting routers also do not have any information on how much bandwidth
 is available at each hop.
 
-This proposal addresses the issue by adding bandwidth parameters to
+Also, routers currently have no way to limit inbound traffic on a tunnel.
+This would be quite useful during times of overload or DDoS of a service.
+
+This proposal addresses these issues by adding bandwidth parameters to
 the tunnel build request and reply messages.
 
 
@@ -56,15 +59,21 @@ For both long and short ECIES build records:
 Build Request Options
 ---------------------------
 
-The following two options may be set in the tunnel build options mapping field of the record:
-A requesting router may include either or both.
+The following three options may be set in the tunnel build options mapping field of the record:
+A requesting router may include any, all, or none.
 
 - m := minimum bandwidth required for this tunnel (KBps positive integer as a string)
 - r := requested bandwidth for this tunnel (KBps positive integer as a string)
+- l := limit bandwidth for this tunnel; only sent to IBGW (KBps positive integer as a string)
+
+Constraint: m <= r <= l
 
 The participating router should reject the tunnel if "m" is specified and it cannot
 provide at least that much bandwidth.
 
+Request options are sent to each participant in the corresponding encrypted build request record,
+and are not visible to other participants.
+
 
 Build Reply Option
 ---------------------------
@@ -86,6 +95,11 @@ participating traffic is lower-priority than a router's own traffic and tunnels.
 Routers may also over-allocate available bandwidth if necessary, and this is
 probably desirable, as other hops in the tunnel could reject it.
 
+For these reasons, the participating router's reply should be treated
+as a best-effort commitment, but not a guarantee.
+
+Reply options are sent to the requesting router in the corresponding encrypted build reply record,
+and are not visible to other participants.
 
 
 Implementation Notes
@@ -108,31 +122,49 @@ More complex algorithms are possible and are up to the implementer.
 
 There are no current I2CP or SAM options defined for the client to tell the
 router what bandwidth is required, and no new options are proposed here.
+Options may be defined at a later date if necessary.
 
 Implementations may use available bandwidth or any other data, algorithm, local policy,
 or local configuration to calculate the bandwidth value returned in the
 build response. Not specified by this proposal.
 
-This proposal does not require participating hops to implement per-tunnel or global
+This proposal requires inbound gateways to implement per-tunnel
+throttling if requested by the "l" option.
+It does not require other participating hops to implement per-tunnel or global
 throttling of any type, or specify a particular algorithm or implementation, if any.
 
 This proposal also does not require client routers to throttle traffic
-to the limit returned by the participating hop, and depending on application,
+to the "b" value returned by the participating hop, and depending on application,
 that may not be possible, particularly for inbound tunnels.
 
+This proposal only affects tunnels created by the originator. There is no
+method defined to request or allocate bandwidth for "far-end" tunnels created
+by the the owner of the other end of an end-to-end connection.
+
 
 
 Security Analysis
 =================
 
-Client fingerprinting based on requests.
+Client fingerprinting or correlation may be possible based on requests.
 The client (originating) router may wish to randomize the "m" and "r" values instead of sending
 the same value to each hop; or send a limited set values that represent bandwidth "buckets",
 or some combination of both.
 
-Avoid over-allocation ddos.
+Over-allocation DDoS: While it may be possible to DDoS a router now by building and
+using a large number of tunnels through it, this proposal arguably makes it much easier,
+by simply requesting one or more tunnels with large bandwidth requests.
 
+Implementations can and should use one or more of the following strategies
+to mitigate this risk:
 
+- Overallocation of available bandwidth
+- Limit per-tunnel allocation to some percentage of available bandwidth
+- Limit rate of increase in allocated bandwidth
+- Limit rate of increase in used bandwidth
+- Limit allocated bandwidth for a tunnel if not used early in a tunnel's lifetime (use it or lose it)
+- Tracking average bandwidth per tunnel
+- Tracking requested vs. actual bandwidth used per tunnel
 
 
 Compatibility
@@ -147,6 +179,9 @@ Migration
 
 Implementations may add support at any time, no coordination is needed.
 
+As there is currently no API version defined where support for this proposal is required,
+routers should check for a "b" response to confirm support.
+
 
 
 References