Re: [bmwg] WG Adoption Call: Stateful NATxy Gateways using RFC 4814

[Gábor LENCSE <[e-mail]>]

Dear Sandor,

Thank you very much for your review and comments. Please see my answers 
inline.

2022.06.13. 18:07 keltezéssel, Sandor R. Repas Dr. írta:
> Dear All,
>
> In my opinion, a standard method for measuring the performance of NAT gateways is very important. So thank Lencse and Shima for the hard work. However, I found some potential problems with the proposal:
> There are three assumptions in In section 4.4 (https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful-03#section-4.4), and the second one is:
>   " 2.  The connection tracking table of the stateful NATxy is large enough to store all connections defined by the different source port number destination port number combinations."
> It seems to be a rather strong assumption. How can one guarantee it?
> Should one test it before the below described measurement methods can be used?

Yes, your questions are completely valid. The hardship is that we need 
this assumption for the maximum connection establishment rate 
measurement to guarantee that loss of the test frames was caused by 
using too high rate and not because the capacity of the connection 
tracking table has been exhausted.

As recommended by Al Morton earlier, now we are working on the 
connection tracking table capacity measurement. In theory, it is ready, 
but we haven't tested it yet. We plan to test it soon with iptables. If 
it will work, then we will be able to guarantee the condition.

> In section 4.5 (https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful-03#section-4.5) the measurement procedure only counts the number of test frames arrived to the Responder, however, it is not checked, whether every single test frame resulted in adding a new connection to the connection tracking table of the DUT. (Can it happen in an overloaded situation that a frame is forwarded but the connection is not registered into the connection to the connection tracking table of the DUT?)
Yes, it can surely happen. We have met this case, when the combination 
of tayga (stateless NAT64) and iptables (stateless NAT44) was used to 
provide a stateful NAT64 gateway (the PLAT part of 464XLAT) using 
virtual machines. At a high enough overload, some of the source IPv4 
addresses were not replaced, as you can see it in Fig. 5 of this paper:

A. Al-Azzawi and G. Lencse, "Identification of the Possible Security 
Issues of the 464XLAT IPv6 Transition Technology", /Infocommunications 
Journal/, vol. 13, no. 4, pp. 10-18, December 2021, DOI: 
10.36244/ICJ.2021.4.2
Full paper in PDF 
<http://www.hit.bme.hu/~lencse/publications/InfocomJ_2021_4_2_Al-Azzawi.pdf>

This is why we wrote the below statement our draft:
> In Note 2: "2. As for the successful translation, the Responder MAY (or SHOULD?)  check that the source IP address is different than the original source IP address set by the Initiator."

The above statement aimed to provide some kind of mitigation for the 
problem. But we plan to remove it from the next version, because:
- it does not guarantee that the connection is really established
- it can be rather inconvenient and inefficient to check it (at least I 
do not have an idea for an efficient implementation in siitperf)
- and, mainly, because we have found a better method (see below). :-)

> However, even if the translation was successful, it is not an ultimate guarantee that the connection was established in the DUT.

We recommend a method for the validation of the connections. Its basic 
idea is that all four tuples extracted from the test frames by the 
Responder MUST be tested by sending test frames with all of them in the 
real test phase at a "low enough" frame rate.

Some tests have already been performed, and we found that validation 
works well.

We planned to submit a new version after the end of the adoption call 
(to avoid the situation that some people are reading the current text 
and we just replace it).

I think this new part is already quite stable, so let me copy it here as 
a preliminary version of the text:

4.6.  Validation of Connection Establishment

    Due to "black box" testing, the entries of the connection tracking
    table of the DUT may not be directly examined, but the presence of
    the connections can be checked easily by sending frames from the
    Responder to the Initiator in the Real Test Phase using all four
    tuples stored in the state table of the Tester (at a low enough frame
    rate).  The arrival of all test frames indicates that the connections
    are really present.

    Procedure: When all the desired N number of test frames were sent by
    the Initiator to the Receiver at frame rate R in the Preliminary
    Phase for the maximum connection establishment rate measurement, and
    the Receiver has successfully received all the N frames, the
    establishment of the connections is checked in the Real Test Phase as
    follows:

    o  The Responder sends test frames to the Initiator at frame rate:
       r=R*alpha, for the duration of N/r using a different four tuple
       from its state table for each test frame.

    o  The Initiator counts the received frames, and if all N frames are
       arrived then the frame rate of the maximum connection
       establishment rate is raised, otherwise lowered (as well as in the
       case if test frames were missing in the preliminary phase).

    Notes:

    o  The alpha is a kind of "safety factor", its aim is to make sure
       that the frame rate used for the validation is not too high, and
       test may fail only in the case if at least one connection is not
       present in the connection tracking table of the DUT.  (So alpha
       should be typically less than 1, e.g.  0.8 or 0.5.)

    o  The duration of N/r and the frame rate of r means that N frame are
       sent.

    o  The order of four tuple selection is arbitrary provided that all
       four tuples MUST be used.

    o  Please refer to Section 4.9 for a short analysis of the operation
       of the measurement and what problems may occur.


We did some tests with Jool using different values for alpha. E.g. using 
0.25 and 0.5, the validated connection establishment rate was the same 
as measured without validation. However, 0.6 and 0.8 proved to be too high.

What do you think about the above method?

Please let us know if you have any concerns or suggestions.

And also, if you are satisfied with my answer. :-)

Best regards,

Gábor

> Best regards,
> Sandor
>
> -----Original Message-----
> From: bmwg<[e-mail]>  On Behalf Of MORTON JR., AL
> Sent: 2022. május 16., hétfő 19:06
> To:[e-mail]
> Cc:[e-mail]
> Subject: [bmwg] WG Adoption Call: Stateful NATxy Gateways using RFC 4814
>
> BMWG,
>
> This message begins a WG Adoption call for
>
>      Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814
>      Pseudorandom Port Numbers
>      https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful-03
>
> The WG Adoption will run from May 16 to June 20, 2022.
>
> BMWG has discussed this draft at several meetings and on the list. There has been a moderate level of interest.
>
> Please review the latest draft and send comments and/or indications of support to the bmwg-list ([e-mail]) and/or to me (acmorton(at)att.com).
>
> Thanks and best regards,
> Al
> bmwg co-chair
>
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg
>
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg
>