[bmwg] security issues of iptables and Jool -- Re: I-D Action: draft-ietf-bmwg-benchmarking-stateful-01.txt

[Gabor LENCSE <[e-mail]>]

Dear Eduard,

Sorry for not responding for a long time. I would like to clarify the 
security issues of ipables and Jool. In fact, they are radically different.

As for iptables, its default values for hashsize and nf_conntrack_max 
are safe. Leaving them untouched guarantees that the memory of the Linux 
system will not be exhausted. They can be changed with root privileges 
to unsafe values, but then it is the responsibility of the system 
administrator.

As for Jool, I have not found any way to set the maximum number of 
connections. (It may exist, but I do not know about it. I would be happy 
to know, if such a setting exists.) Using Jool with its default values 
one can exhaust the memory of the Linux system by using too many 
connections. So you are completely right, this is a serious vulnerability!

I was aware of this problem and thus our algorithm for measuring the 
connection tracking table capacity can theoretically handle the problem 
like this:

    if ( DUT_collapsed || RT < RS*beta )
      break;

In practice, the Tester can detect if the DUT has been collapsed. (E.g. 
it does not reply to ping.) However, it has some practical difficulty to 
restart it. Currently I use Dell PowerEdge 430 servers, that have iDRAC 
8 (Integrated Dell Remote Access Controller 8) management software. I 
can easily restart it manually after logging in and clicking the to 
right place in the GUI. However, I would need to do it remotely from the 
bash shell script that performs the measurement.

Best regards,

Gábor


On 11/21/2022 5:12 PM, Vasilenko Eduard wrote:
>
> Hi Keiichi,
>
> It is a good point that BMWG typically tests just one parameter at a 
> time. Or else a huge permutation of possible tests may become a reality.
>
> For me, it looks important to stay in the linear proportion region (if 
> possible). It gives the possibility to combine test results for the 
> estimation of something in the business.
>
> For example, if the box has X FIB routes for IPv4, typically it has 
> X/4 FIB routes for IPv6. Then it is possible to guess about a mixed 
> environment (combination of Y IPv6 and Z IPv4) creating a proportion 
> where IPv6 occupies 4x FIB resources. X=Z+4Y.
>
> I am just trying to find an orthogonal basis for tests.
>
> If the basic tests for the stateful device would be “maximum sessions 
> connection and teardown per second in the stable load environment” 
> then this number could participate in other calculations that are real 
> for business.
>
> Unfortunately, for stateful devices, the correlation between cps 
> (connection + teardown) and pps is very tight. I believe linear.
>
> Hence, if we have maximum pps and maximum cps (connection + teardown) 
> then we would be capable to estimate some real business situations (in 
> a linear proportion).
>
> If we would have a separate “maximum connection rate” and “maximum 
> teardown rate” then the network owner would have more challenges to 
> guess the performance in his environment. It is still possible to 
> create a linear proportion from 3 parameters, just it would be more 
> difficult and the error would be bigger because could be some 
> dependency between the session connection and teardown.
>
> I am not asking to bloat the tests.
>
> I am asking for 2 tests (just connection, and connection + teardown) 
> instead of the other 2 tests (connection, and teardown).
>
> because it gives more value to the business.
>
> But the test for “connection + teardown” looks already mixed. That 
> formally breaks BMWG's practice to test only one parameter at a time.
>
> Hence, it is up to the group's consensus. Maybe I am wrong here and we 
> should stay in the pure theoretical zone.
>
> PS: not all my comments below are related to this problem.
>
> Eduard
>
> *From:*Keiichi SHIMA [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 9:33 AM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* Keiichi SHIMA <[e-mail]>; Gabor LENCSE 
> <[e-mail]>; [e-mail]
> *Subject:* Re: [bmwg] I-D Action: 
> draft-ietf-bmwg-benchmarking-stateful-01.txt
>
> Hello Vasilenko Eduard
>
> I am Keiichi SHIMA, co-author of the draft.
>
> In my understandings, you are trying to define methodology to measure 
> the performance of a translator box under the similar traffic patterns 
> (and similar device configuration) to the real traffic pattern / 
> device configuration. But our draft 
> (draft-ietf-bmwg-benchmarking-stateful) is focusing on the same 
> methodology defined in RFC8219 (and RFC5180, RFC2544) with some 
> enhancements for supporting random port numbers (suggested in RFC4814) 
> and some additional metrics (e.g. connection establishment rate). So 
> we basically follow the same benchmarking methods defined in RFC8219 
> (and former RFCs).
>
> Actually RFC8219 doesn’t consider the traffic patters you mentioned 
> and doesn’t support device configurations which multiple ports are 
> connected to one routing (or translating) engine. It may be a new 
> discussion point to enhance RFC8219 (and/or former RFCs). Probably in 
> a separate Internet Draft.
>
> Regards,
>
> ---
>
> Keiichi SHIMA (島慶一)
>
> WIDE project <[e-mail]>
>
> PGP: 9D95 8544 A5CE D530 9230  DF1C BB6E ABE1 D91F EDFC
>
>