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
Once FIN packets are seen in both directions, application data can no
longer be exchanged, but the stacks still need to ensure that the FIN
packets are received (TCP states: CLOSING and LAST_ACK).
5.
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?
6. 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 (#20679): https://lists.fd.io/g/vpp-dev/message/20679
Mute This Topic: https://lists.fd.io/mt/88218698/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
