Thank you very much, Klement! I have pushed my current patch for the FIN re-transmission and new SYN matching a closed session in transitory problems, in case it helps you in any way. The SYN part does not have a test case yet. https://gerrit.fd.io/r/c/vpp/+/34873
Thanks, Miklos ________________________________ From: Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco) <ksek...@cisco.com> Sent: Monday, January 10, 2022 12:35 PM To: Miklós Tirpák <miklos.tir...@emnify.com>; vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] NAT44-ed state machine CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Miklos, I agree with your points and I think the whole tracking is non-rfc compliant. I’m implementing a better state machine and hoping to push a patch later today which would make it rfc compliant. For now I would not attempt to fix the bit flags … Thanks, Klement From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Miklos Tirpak <miklos.tir...@emnify.com> Date: Monday, January 10, 2022 at 12:33 PM To: vpp-dev <vpp-dev@lists.fd.io>, Miklós Tirpák <miklos.tir...@emnify.com> Subject: Re: [vpp-dev] NAT44-ed state machine Hi, I have opened the review https://gerrit.fd.io/r/c/vpp/+/34851<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.fd.io%2Fr%2Fc%2Fvpp%2F%2B%2F34851&data=04%7C01%7Cmiklos.tirpak%40emnify.com%7C2f408113b7c843885e4208d9d42d51ff%7Cf644ad61a00a4982bed140ea728f0209%7C0%7C0%7C637774113383982932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NEtbhB4v%2F4Kp5YP%2FR0sWA%2Bw9JB%2BEPdIOezAoGkGPS4k%3D&reserved=0> for the first issue, the [SYN, ACK] retransmission. Could you please have a look? Thanks, Miklos ________________________________ From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Miklos Tirpak via lists.fd.io <miklos.tirpak=emnify....@lists.fd.io> Sent: Wednesday, January 5, 2022 6:23 PM To: vpp-dev <vpp-dev@lists.fd.io> Subject: [vpp-dev] NAT44-ed state machine CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7857%23section-2&data=04%7C01%7Cmiklos.tirpak%40emnify.com%7C2f408113b7c843885e4208d9d42d51ff%7Cf644ad61a00a4982bed140ea728f0209%7C0%7C0%7C637774113383982932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=I36jgwINa3KUurjfdnb6ci3%2B9b1PHpo29SKx5XIoOx4%3D&reserved=0>, 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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5382%23section-5&data=04%7C01%7Cmiklos.tirpak%40emnify.com%7C2f408113b7c843885e4208d9d42d51ff%7Cf644ad61a00a4982bed140ea728f0209%7C0%7C0%7C637774113383982932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=adjsmuSXeQVXy1doVK96wOHOrqM5ZGch6NIn5FkQHuA%3D&reserved=0> 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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6146%23section-3.5.2.2&data=04%7C01%7Cmiklos.tirpak%40emnify.com%7C2f408113b7c843885e4208d9d42d51ff%7Cf644ad61a00a4982bed140ea728f0209%7C0%7C0%7C637774113383982932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s%2B%2BQmp5zMaxU4hV%2BHkjCFFpBZ4pYJAy9fqpzV%2FkdFAY%3D&reserved=0>: *** 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6146%23section-3.5.2.2&data=04%7C01%7Cmiklos.tirpak%40emnify.com%7C2f408113b7c843885e4208d9d42d51ff%7Cf644ad61a00a4982bed140ea728f0209%7C0%7C0%7C637774113383982932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s%2B%2BQmp5zMaxU4hV%2BHkjCFFpBZ4pYJAy9fqpzV%2FkdFAY%3D&reserved=0> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5382%23section-5&data=04%7C01%7Cmiklos.tirpak%40emnify.com%7C2f408113b7c843885e4208d9d42d51ff%7Cf644ad61a00a4982bed140ea728f0209%7C0%7C0%7C637774113383982932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=adjsmuSXeQVXy1doVK96wOHOrqM5ZGch6NIn5FkQHuA%3D&reserved=0> 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 (#20692): https://lists.fd.io/g/vpp-dev/message/20692 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] -=-=-=-=-=-=-=-=-=-=-=-
