Re: [PATCH nf] netfilter: conntrack: sctp: use distinct states for new SCTP connections

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18/01/2020 21:39, Pablo Neira Ayuso wrote:
On Sat, Jan 18, 2020 at 01:10:50PM +0100, Jiri Wiesner wrote:
The netlink notifications triggered by the INIT and INIT_ACK chunks
for a tracked SCTP association do not include protocol information
for the corresponding connection - SCTP state and verification tags
for the original and reply direction are missing. Since the connection
tracking implementation allows user space programs to receive
notifications about a connection and then create a new connection
based on the values received in a notification, it makes sense that
INIT and INIT_ACK notifications should contain the SCTP state
and verification tags available at the time when a notification
is sent. The missing verification tags cause a newly created
netfilter connection to fail to verify the tags of SCTP packets
when this connection has been created from the values previously
received in an INIT or INIT_ACK notification.

A PROTOINFO event is cached in sctp_packet() when the state
of a connection changes. The CLOSED and COOKIE_WAIT state will
be used for connections that have seen an INIT and INIT_ACK chunk,
respectively. The distinct states will cause a connection state
change in sctp_packet().
This problem shows through conntrack -E, correct?

Thanks.
Yes, although "conntrack -E" does not display verification tags. These are the first 3 notifications of an association as printed by "conntrack -E" (output truncated after src=):
    [NEW] ipv4     2 sctp     132 3 src=
 [UPDATE] ipv4     2 sctp     132 3 src=
 [UPDATE] ipv4     2 sctp     132 3 COOKIE_ECHOED src=
As you see, there is no connection state printed in the first two notifications.

I used a custom tool which can print verification tags and formats its output similarly to "conntrack -E":
    [NEW] ipv4     2 sctp     132 3 0 0 src=
 [UPDATE] ipv4     2 sctp     132 3 0 0 src=
 [UPDATE] ipv4     2 sctp     132 3 COOKIE_ECHOED 50ced389 e967350e src=
The tags are printed as zero in the first two notifications, but that rather means the tags have not been received in the notification. The above test was done under Linux 5.5-rc4.



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux