[Jool-list] Jool at the Internet2 Tech Exchange

[Tore Anderson]

* 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