* Alberto Leiva > The solution will be somewhat more viable if you throw --mark into the > mix (https://jool.mx/en/usr-flags-pool4.html#--mark). The reason for > this is that pool4 entries wearing different marks are basically members > of different pools, so if you have this pool4, for example (Note the > first column, which represents the mark): > > $ jool --pool4 --display > 0 TCP 192.0.2.1 1-65535 > 1 TCP 192.0.2.2 1-65535 > 2 TCP 192.0.2.3 1-65535 > 3 TCP 192.0.2.4 1-65535 > > Then the peak of the graph will be 65535 for any connection (as opposed > to 4 * 65535). This would have the added benefit that, if one of your > users is attacking you, he or she will only mess up their own pool4 and > not affect everyone else.
This is nice, but if your user population is large (imagine a public NAT64 instance serving the entire Internet), it gets problematic to pre-allocate these client-private pool4s. So I was thinking: What if Jool could dynamically allocate a private «BIB pool» containing $X ports whenever a new client comes along? Where «client» here actually means a /$Y mask (typically /64 or /56 or /48). Assume pool4 is 192.0.2.0/24, X=128, and Y=64. - Client 2001:db8:1:1::1 comes along (first time seen), initiating a new TCP session. - Jool proceeds to allocate a «BIB pool» of 2001:db8:1:1::/64 - 192.0.2.0:[128-255]. This event should be logged for abuse tracing purposes. - Jool picks 192.0.2.0:128 as source v4/port of the connection in question. - A second connection from 2001:db8:1:1::2 comes along. Since it's the same /64, no new «BIB pool» is allocated. Instead a source v4:port is picked from 192.0.2.0:[128-255] (if «fake NAT64» is enabled, could even be 192.0.2.0:128 even though there's another active session using that tuple, provided the destination is different). - A third connection from 2001:db8:1:2::3 comes along. Since it's not in the same /64 as the previous two, a new BIB pool (192.0.2.0:[256-383]) is allocated (and logged), and the source v4:port gets picked from there. - Turns out, 2001:db8:1:1::/64 belongs to Sander and his T-Rex, and he's spamming new connections. The algorithm gets slow as it tries hard to find free v4:port tuples in 192.0.2.0:[128-255], but only for Sander, not for clients in 2001:db8:1:2::/64 or anywhere else. - When 192.0.2.0:[128-255] is completely exhausted, Jool could possibly allocate (and log) another batch of 128 ports. Now 2001:db8:1:1::/64 is allocated 192.0.2.0:[128-255] and 192.0.2.0:[384-511]. This would allow for having the default port-set size reasonably small, while still allowing for «power users» to get all the ports they're likely to need. - Administrator should be able to limit the maximum number of extra batches each client/mask should be allowed to obtain (could even be 0). This would ensure Sander's T-Rex couldn't monopolise the entire pool4 all by himself and/or grind Jool to a halt for all clients. - 2001:db8:1:2::3 has gone to bed and there are no longer any active sessions using the 192.0.2.0:[256-383] pool. Jool deallocates it (after a configurable grace period, perhaps?), logging that it does so. Later, perhaps after a configurable quarantine period, it would reallocate it to another client/mask. Tore _______________________________________________ Jool-list mailing list [email protected] https://mail-lists.nic.mx/listas/listinfo/jool-list
