Hi, Following up on this thread. The changes in 34877 led to some undesired behaviour in the "real world(tm)". In the close pattern below it left sessions in established state, and with a relatively low cps would consume the whole session table.
The change here https://gerrit.fd.io/r/c/vpp/+/35692 nat: tweak rfc7857 tcp connection tracking proposes to move the needle somewhat more towards protecting the session table. Views? Miklos, Klement? The RFC7857 state machine introduced in 56c492a is a trade-off. It tries to retain sessions as much as possible and also offers some protection against spurious RST by re-establishing sessions if data is received after the RST. From experience in the wild, this algorithm is a little too liberal, as it leaves too many spurious established sessions in the session table. E.g. a oberserved pattern is: client server <- FIN, ACK ACK -> ACK -> RST, ACK -> With the current state machine this would leave the session in established state. These proposed changes do: - require 3-way handshake to establish session. (current requires only to see SYNs from both sides) - Any FIN or RST will move session to transitory without recovery to established Best regards, Ole > On 12 Jan 2022, at 21:38, Klement Sekera via lists.fd.io > <ksekera=cisco....@lists.fd.io> wrote: > > Dear vpp-dev, > > Based on below and after discussion with both Miklos and Andrew I have > implemented new TCP state tracking for endpoint-dependent NAT44. > > Most of the behavior is in line with RFC 7857 and 6146 except for VPP > supporting session reopening while an old session is closed (meaning, both > FINs have been seen in both directions) by observing SYN packets from both > directions. We had a chat with Andrew and couldn’t find any reason why this > would break stuff and agreed that it can only help clients to achieve fast > connection restart should they wish to do so. Old behavior was to drop all > traffic in transitory timeout until session was completely removed from NAT > state. > > Proposed code is here: > > https://gerrit.fd.io/r/c/vpp/+/34877 > > A document w/graph describing TCP state tracking is part of the change: > > https://gerrit.fd.io/r/c/vpp/+/34877/7/src/plugins/nat/nat44-ed/tcp_conn_track.rst > > Thanks, > Klement > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Miklos Tirpak > <miklos.tir...@emnify.com> > Date: Wednesday, January 5, 2022 at 6:23 PM > To: vpp-dev <vpp-dev@lists.fd.io> > Subject: [vpp-dev] NAT44-ed state machine > > Hi, > > we have observed couple of problems with the NAT44-ed state machine and would > appreciate your advice to fix them. In our use case, the clients can have a > lossy connection, which results in retransmissions. In some cases, these > retransmissions do not seem to be handled correctly. > > • The server retransmits the [SYN, ACK], the state is left non-zero and > the transitory timer is applied for the entire session. > > [SYN] -> > X <- [SYN, ACK] > <- [SYN, ACK] > The session state is set to 0 and then to NAT44_SES_O2I_SYN when routing the > retransmitted packet. > [ACK] -> > > As far as I see in https://datatracker.ietf.org/doc/html/rfc7857#section-2, > the state should be set to established when the SYNs are received from both > sides, without waiting for the ACK. > • The FIN is retransmitted because of a lost ACK and the > tcp_closed_timestamp has already been set. VPP drops every packet in this > closed state. > > <- [FIN] > [FIN, ACK] -> > • X <- [ACK] > • VPP starts dropping after this step, but there is no guarantee that > the ACK will arrive. > [FIN, ACK] -> > [FIN, ACK] -> > ... > > https://datatracker.ietf.org/doc/html/rfc5382#section-5 says > 5. Once FIN packets are seen in both directions, application data can no > 6. longer be exchanged, but the stacks still need to ensure that the FIN > packets are received (TCP states: CLOSING and LAST_ACK). > 7. > Letting the FINs and ACKs go through would fix this issue. > However, the newer RFC 7857 simplifies the state machine as far as I see, and > it references RFC 6146 (the state machine the NAT64 plugin also implements). > From https://datatracker.ietf.org/doc/html/rfc6146#section-3.5.2.2: > > *** V6 FIN + V4 FIN RCV *** > > All packets are translated and forwarded. > > I am wondering if data can still arrive because of packet re-ordering and > whether it should be forwarded. Could this be the background of this sentence > in RFC 6146? > > • The client reuses the port within the transitory time. > > When a SYN is received that matches a closed session in transitory state, the > packet is dropped and the connection cannot be established. RFC 5382 mentions > a similar case as externally initiated connection, and it is implementation > dependent whether or not to allow that. We have, however seen this in > in-2-out direction 40 seconds after the previous session has been closed. It > would be nice to allow this at least in this direction. > The above mentined RFC updates seem to be a contradictional to me, RFC 7857 > simplifies the state machine but does not mention case 3 anymore, for > example. Would it be better to fix the existing state machine in nat44-ed, or > do you think it should look similar to the one in nat64 instead? > > Thanks, > Miklos > rfc6146 - IETF Datatracker > RFC 6146 Stateful NAT64 April 2011 1.Introduction This document specifies > stateful NAT64, a mechanism for IPv4-IPv6 transition and IPv4-IPv6 > coexistence. Together with DNS64 [], these two mechanisms allow an IPv6-only > client to initiate communications to an IPv4-only server.They also enable > peer-to-peer communication between an IPv4 and an IPv6 node, where the > communication can be initiated ... > datatracker.ietf.org > > > > > > rfc5382 - IETF Datatracker > RFC 5382 NAT TCP Requirements October 2008 Recently, many techniques have > been devised to make peer-to-peer TCP applications work across NATs. [], [], > and [] describe Unilateral Self-Address Fixing (UNSAF) mechanisms that allow > peer-to-peer applications to establish TCP through NATsThese approaches > require only endpoint applications to be modified and work with standards > compliant OS stacks. > datatracker.ietf.org > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21060): https://lists.fd.io/g/vpp-dev/message/21060 Mute This Topic: https://lists.fd.io/mt/88218698/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
