On Mon, Mar 14, 2022 at 10:38:46AM +0100, Remi Locherer wrote:
> This is how OpenBSD responds with pf disabled:
> 192.168.201.21.20 > 192.168.201.29.22: SF 0:0(0) win 8192
> 192.168.201.29.22 > 192.168.201.21.20: S 2641340782:2641340782(0) ack 1 win
> 16384 <mss 1460> (DF)
>
> So pf behaves kind of similar to that.
This matches what I read in tcp_input().
> But even with T/TCP or TFO, I don't a legit use of a TCP packet with
> SYN and FIN set together.
You can send a SYN, Data (e.g. HTTP Request) and FIN (EOF) in one
packet. Our stack does not support this and ignores Data and FIN.
> If we want to handle TFO then pf should probably inspect the TFO
> option header and coocky.
That's a different story. For now we should stay compatible and
improve security. I am not sure what we should do to achieve this.
> With pf disabled:
> 192.168.201.21.20 > 192.168.201.29.22: SF [tcp sum ok] 0:1000(1000) ack 0 win
> 8192 (ttl 64, id 1, len 1040)
> 192.168.201.29.22 > 192.168.201.21.20: R [tcp sum ok] 0:0(0) win 0 (DF) (ttl
> 64, id 55619, len 40)
A misunderstanding. I wanted to see
192.168.201.21.20 > 192.168.201.29.22: S [tcp sum ok] 0:1000(1000) win 8192 (t
tl 64, id 1, len 1040)
192.168.201.29.22 > 192.168.201.21.20: SF [tcp sum ok] 689392523:689392523(0) a
ck 1 win 16384 <mss 1460> (DF) (ttl 64, id 10777, len 44)
I would expect the next ACK acknowledges the FIN.
As our stack does not support this, it is a bit tricky to generate.
When sending scpay packets the stack must not interfere. I solved
a somehow simmilar problem in src/regress/sys/net/pf_state.
> Did T/TCP specify the combination of SYN and FIN flags?
2.2 Transaction Sequences
CLOSED LISTEN
#1 SYN-SENT* --> <SYN,data1,FIN,CC=x> --> CLOSE-WAIT*
#2 TIME-WAIT <-- <SYN,ACK(FIN),data2,FIN,CC=y,CC.ECHO=x> <-- LAST-ACK*
> With TFO a client can send a cookie and data together with the SYN.
> But a FIN flag? I did not find a hint for that in the RFC.
I did not find SYN+FIN in TFO RFC. Probably they only think about
HTTP connection keep-alive. But why not? FIN is just end of data.
When you can send data, you can also append FIN in the same packet.
> > Or should we strip data and FIN from both SYN packets to disable
> > TFO?
Don't know. Perhaps it is the other way around. Without TFO SYN+FIN
looks stange. As T/TCP is obsolete, I guess it is not allowed in
the generic initial SYN-Packet. But SYN+ACK+FIN may be different.
> In the TCP stack or pf?
The stack can do what it supports. pf should protect other stacks.
We are talking about normalize TCP. There we can remove everything
that looks strange and could confuse foreign TCP stacks. But we
should not block things that are used in the wild. Maybe that was
the idea to strip the FIN instead of dropping the packet.
bluhm
