On Wed, 2 Jun 2010, Curby wrote: > This seems to get a bit murkier as some conditions that match INVALID, > including invalid combinations of TCP flags, seem to be an "active > match" instead of a "passive default." In other words, if the state > starts as INVALID, and conntrack determines that it should be state > NEW, something somehow must be applied afterwards to force it back to > INVALID due to it being a malformed packet. It depends on how one looks at conntrack and it's relation with the other parts of netfilter. I'd not say that "every packet starts with the state INVALID". Of course the state of the packet *before* conntrack invoked is INVALID, but what else could it be, if conntrack hadn't got a chance yet to associate a state to the packet? The current documentations try to describe the states so that it does not need a deep TCP/IP knowledge from the readers. A rough description on how a packet traverses conntrack and what state are associated to it could be the following: - loopback or untracked packets are ignored - if the IP(v4/6) header cannot be extracted then the packet is dropped - if the packet, according to the Layer 4 protocol, is broken (like for TCP: the packet does not carry a complete TCP header or it's malformed or the TCP checksum/TCP flag combination is invalid; for UDP: the header is too small, truncated or malformed, etc.) then the INVALID state is associated to the packet - if the IP addresses or the protocol parameters (ports) for a unique tuple (src ip, dst ip, proto, src "port", dst "port") cannot be extracted from the packet, it's state is set to INVALID - then, using the tuple, we try to find an already existing connection to which the packet belongs. If we do find such a connection, then a lot of checking happens according to the protocol. Just for TCP, those can result in dropping simply the packet (like when we cannot handle reopened connections or when conntrack lost sync and that way we can force the client to resend an initial SYN); or set the state to INVALID (when it's s SYN/ACK packet and we haven't seen a SYN previously, or it's a FIN "answering" a SYN packet, or invalid RST segment, or out of window packet, etc). If the packet is OK and associated to a connection, then it's state will be ESTABLISHED. - if we could not find an already existing connection for the packet then it's state will be NEW - or RELATED, if we expected the packet. Or INVALID, if the given packet may not initiate a new connection, according to the protocol (and tcp_loose is disabled for TCP). I left out smaller parts and referred TCP mostly. However there are ICMP subleties, and other handled protocols as well. So the full picture would need a complete article. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
