[Jool-list] Jool at the Internet2 Tech Exchange

[Alberto Leiva]

I think that you're talking about dynamic port assignments, no?
https://tools.ietf.org/html/draft-ietf-sunset4-nat64-port-allocation-01#section-2.2.2

We already have an issue for that (#175), but I gave it less priority than
the framework switch (#140).
Mainly because there's so much right now that depends on #140. I'm even
being my usual naive again, hoping that we might get rid of GRO/LRO by
being a device driver.
(I was deeply submerged in #140 before this week's avalanche of issues came
up.)

I'd rather work on #140 since we've been postponing it for so long, but you
know I get pumped up about whatever generates buzz. I think I recall that
you've already complained about the static assignments, but I didn't get
the impression that it was more than academic curiosity/experimentation
back then. I guess I was wrong; you do seem to care about it quite a bit.

Cast a vote on #175?

On Fri, Sep 8, 2017 at 3:23 PM, Tore Anderson <tore at fud.no> wrote:

> * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail-lists.nic.mx/pipermail/jool-list/attachments/20170908/edb22d47/attachment.html>