[Jool-list] Jool at the Internet2 Tech Exchange

[Alberto Leiva]

> think that you're talking about dynamic port assignments

My bad. I think that's not exactly what's called "dynamic port
assignments". I think the idea is kind of better explained in section 3.4.
Or something like that. Or more like it's scattered all over the draft. But
whatever.

On Fri, Sep 8, 2017 at 11:38 PM, Alberto Leiva <ydahhrk at gmail.com> wrote:

> 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/fe8f2e5b/attachment-0001.html>