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. 1. 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. 2. 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] -> 3. X <- [ACK] 4. 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? 1. 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<https://datatracker.ietf.org/doc/html/rfc6146#section-3.5.2.2> 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<https://datatracker.ietf.org/doc/html/rfc5382#section-5> 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 (#20701): https://lists.fd.io/g/vpp-dev/message/20701 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] -=-=-=-=-=-=-=-=-=-=-=-
