ydahhrk
commented
8 years ago Well, we have challenged the law before. Mostly thanks to Tore, it seems :)
Jool does not currently track TCP seqs at all (not even the upcoming 3.5 release), but it will have to be implemented eventually if we want to support FTP.
I don't remember the details from when I started trying to fix FTP, but I do recall thinking it was going to be a lot of work. In fact, it might be effort better spent merging Jool with the kernel, because that should enable us access to iptables's seq tracking code. (And also the FTP NAT44 ALG.)
I know RFC6146 section 3.5.2.2 states that RSTs should be handled only for connections in
ESTABLISHEDstate (moving them toTRANS) but I wonder whether an optional configuration argument can be added to Jool to allow it to process RSTs inFIN RCVstates too.What I mean has already been discussed on BEHAVE:
Before I say anything else, I'd like to point out that Dmitry Anipko did not suggest the state should be moved to TRANS; he merely proposed to shorten the timer: From "the maximum session lifetime" (usually TCP_EST) to "the established connection idle timeout" (usually TCP_TRANS).
The distinction is important because the FIN RCV states are meant to never return to ESTABLISHED, while TRANS does.
Edit: Oops. I failed you realize you were linking to Murari Sridharan's message, not to Dmitry's. I do not understand why Murari changed the idea, but see below.
do you think that blindly trusting the RST and moving the state to TRANS, leaving to the hosts the validation effort, would suffice?
It won't work as advertised 100% of the time:
A -------- N ----+--- B
|
+--- M
A = IPv4 node
N = NAT64
B = IPv6 node
M = Malicious nodeLet's say A and B are exchanging packets. N is in the ESTABLISHED state.
- A has nothing left to send, so it sends v4 FIN. B is still sending packets, so it doesn't. N therefore hangs in the
V4 FIN RCVstate, waiting for B's FIN. (This is normal.) - M sends a RST to A in B's name.
- N moves to
TRANS. Let's say the sequence number is not right so N could have technically detected the hijack. - A (or a firewall between A and N) detects the problem and drops the packet.
- B keeps sending packets so N moves from
TRANStoESTABLISHED.
We have a problem now; N is in ESTABLISHED even though it should still be in V4 FIN RCV.
- B eventually shuts up and sends FIN. N moves to
V6 FIN RCV. - N hangs at
V6 FIN RCVfor two hours because A's FIN happened a long time ago...
Dmitry's solution doesn't have this problem as far as I can tell. Its only drawback is that the RST is going to break the connection if the endpoints do not exchange data during the TCP_TRANS period.
(But if my home's ISP is of any indication, this is normal even without NAT64s in the way :P. Then again, it's pretty brittle in general.)
I really don't have any objections to coding this, but it would not be enabled by default.
if Jools does not implement seq checking, do you think it's worth and "politically correct" to spend some efforts on it to strengthen the FIN RCV -> TRANS transition on RST receipt?
Noooooope :). Seqnum tracking is a lot of code for just this purpose, and since the filtering topic raised a lot of controversy I'd say it's fairly safe to assume the IETF rejected the idea during one of the meetings. (I cannot say the same for Dmitry's proposal however, as it kind of looks like they forgot about it.)
But if we end up implementing seq checking anyway due to FTP, then improving RST analysis immediately after would be rather inevitable.
tl;dr
I'm in for implementing Dmitry's proposal, which is not about moving to TRANS from FIN RCV.
Filtering bad RSTs may eventually happen, but I'd say it's unlikely in the near future. (unless someone can propose some clever code)
Objections?
pierky
laura-zelenku
Hello,
during some tests I've noticed that many TCP connections move to the
V4_FIN_RCV/V6_FIN_RCVstates and stay there up to 2 hours (TCP_EST), even if they are actually terminated on the hosts. Stuck connections adversely impact resource usage on a NAT64 box.As far as I can see from some tcpdump captures TCP RSTs are involved in all these connections, for example RST sent in response to FIN with no more packets to follow.
I know RFC6146 section 3.5.2.2 states that RSTs should be handled only for connections in
ESTABLISHEDstate (moving them toTRANS) but I wonder whether an optional configuration argument can be added to Jool to allow it to process RSTs inFIN RCVstates too.What I mean has already been discussed on BEHAVE:
link to message
Of course RST handling needs a special attention about sequencing to mitigate attacks, and this introduces another topic: firewalling/filtering on a NAT64 box. Many considerations have already been written about this too:
link to message
link to message
link to message
I don't know if internally Jool already implements sequencing checks, so if you think my proposal could be taken into account I would also ask
FIN RCV->TRANStransition on RST receipt?TRANS, leaving to the hosts the validation effort, would suffice?Thank you for considering my request.