conntrack: ICMP type 3 code 3 responses should break TCP connections

conntrack: ICMP type 3 code 3 responses should break TCP connections

[Israel G. Lugo]

Hi,

I'm setting up a small embedded router. One of my hosts is running its
own local firewall, using -j REJECT for unwanted traffic (reject the
connection with ICMP destination unreachable, port unreachable). The
router is still keeping track of these connections, though. It will see
the connection as state SYN_SENT, UNREPLIED.

tcpdump on the connecting side (10.0.50.128) shows the ICMP error is
sent and received (goes through the router):
> IP 10.0.50.128.53008 > 10.0.0.18.6666: Flags [S], seq 866150038, win
> 14600, options [mss 1460,sackOK,TS val 987769 ecr 0,nop,wscale 6],
> length 0
> IP 10.0.0.18 > 10.0.50.128: ICMP 10.0.0.18 tcp port 6666 unreachable,
> length 68

The client software (in this case netcat) reports connection refused, as
expected. However, on the router the connection stays there:

> # grep 6666 /proc/net/nf_conntrack
> ipv4     2 tcp      6 110 SYN_SENT src=10.0.50.128 dst=10.0.0.18
> sport=53008 dport=6666 [UNREPLIED] src=10.0.0.18 dst=10.0.50.128
> sport=6666 dport=53008 mark=0 use=2


If I modify the 10.0.0.18 host to reject with a TCP RST instead, the
router's conntrack will drop the connection from its table, as expected.
I believe the same should happen with the hard ICMP error message.

A similar subject has already been covered in a recent thread, although
at the time the focus was on traffic accounting:

http://marc.info/?t=131073077400006&r=1&w=2

I'm more worried about the actual connection table entry remaining
there. It will stay in SYN_SENT for the default time of 120 seconds,
where in my opinion the connection should in fact be forgotten
(connection table size, resource exhaustion, etc.) -- it is my
interpretation that a hard ICMP Destination Unreachable message is
equivalent in this context to a TCP RST.

Quoting RFC1122 (Requirements for Internet Hosts) section 3.2.2.1:

> A Destination Unreachable message that is received MUST be
> reported to the transport layer.  The transport layer SHOULD
> use the information appropriately; for example, see Sections
> 4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
> that has its own mechanism for notifying the sender that a
> port is unreachable (e.g., TCP, which sends RST segments)
> MUST nevertheless accept an ICMP Port Unreachable for the
> same purpose.

and section 4.2.3.9:

> TCP MUST act on an ICMP error message passed up from the IP
> layer, directing it to the connection that created the
> error.  The necessary demultiplexing information can be
> found in the IP header contained within the ICMP message.
> [...]
>
> o    Destination Unreachable -- codes 2-4
>
>      These are hard error conditions, so TCP SHOULD abort
>      the connection.

Codes 2-4 correspond to protocol unreachable, port unreachable and
datagram too big, and are described as hard errors which should abort
the connection. The RFC does not mention what should be done with a code
10 (host administratively prohibited) or code 13 (communication
administratively prohibited, defined in RFC1812), but I would interpret
those as hard errors as well.

I propose that conntrack should drop a connection once it sees a related
ICMP type 3, code {2,3,4,10,13} message. What does everyone else think?

Best regards,
Israel G. Lugo

Re: conntrack: ICMP type 3 code 3 responses should break TCP connections

[Jozsef Kadlecsik]

Hi,

On Mon, 12 Sep 2011, Israel G. Lugo wrote:

> I'm setting up a small embedded router. One of my hosts is running its
> own local firewall, using -j REJECT for unwanted traffic (reject the
> connection with ICMP destination unreachable, port unreachable). The
> router is still keeping track of these connections, though. It will see
> the connection as state SYN_SENT, UNREPLIED.
> 
> tcpdump on the connecting side (10.0.50.128) shows the ICMP error is
> sent and received (goes through the router):
> > IP 10.0.50.128.53008 > 10.0.0.18.6666: Flags [S], seq 866150038, win
> > 14600, options [mss 1460,sackOK,TS val 987769 ecr 0,nop,wscale 6],
> > length 0
> > IP 10.0.0.18 > 10.0.50.128: ICMP 10.0.0.18 tcp port 6666 unreachable,
> > length 68
> 
> The client software (in this case netcat) reports connection refused, as
> expected. However, on the router the connection stays there:
> 
> > # grep 6666 /proc/net/nf_conntrack
> > ipv4     2 tcp      6 110 SYN_SENT src=10.0.50.128 dst=10.0.0.18
> > sport=53008 dport=6666 [UNREPLIED] src=10.0.0.18 dst=10.0.50.128
> > sport=6666 dport=53008 mark=0 use=2
>  
> If I modify the 10.0.0.18 host to reject with a TCP RST instead, the
> router's conntrack will drop the connection from its table, as expected.
> I believe the same should happen with the hard ICMP error message.
> 
> A similar subject has already been covered in a recent thread, although
> at the time the focus was on traffic accounting:
> 
> http://marc.info/?t=131073077400006&r=1&w=2
> 
> I'm more worried about the actual connection table entry remaining
> there. It will stay in SYN_SENT for the default time of 120 seconds,
> where in my opinion the connection should in fact be forgotten
> (connection table size, resource exhaustion, etc.) -- it is my
> interpretation that a hard ICMP Destination Unreachable message is
> equivalent in this context to a TCP RST.
> 
> Quoting RFC1122 (Requirements for Internet Hosts) section 3.2.2.1:
> 
> > A Destination Unreachable message that is received MUST be
> > reported to the transport layer.  The transport layer SHOULD
> > use the information appropriately; for example, see Sections
> > 4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
> > that has its own mechanism for notifying the sender that a
> > port is unreachable (e.g., TCP, which sends RST segments)
> > MUST nevertheless accept an ICMP Port Unreachable for the
> > same purpose.
> 
> and section 4.2.3.9:
> 
> > TCP MUST act on an ICMP error message passed up from the IP
> > layer, directing it to the connection that created the
> > error.  The necessary demultiplexing information can be
> > found in the IP header contained within the ICMP message.
> > [...]
> >
> > o    Destination Unreachable -- codes 2-4
> >
> >      These are hard error conditions, so TCP SHOULD abort
> >      the connection.
> 
> Codes 2-4 correspond to protocol unreachable, port unreachable and
> datagram too big, and are described as hard errors which should abort
> the connection. The RFC does not mention what should be done with a code
> 10 (host administratively prohibited) or code 13 (communication
> administratively prohibited, defined in RFC1812), but I would interpret
> those as hard errors as well.
> 
> I propose that conntrack should drop a connection once it sees a related
> ICMP type 3, code {2,3,4,10,13} message. What does everyone else think?

Yes, at present ICMP(v6) error codes does not terminate TCP connections in 
conntrack. The problem with acting at receiving ICMP error codes is that 
it's easier to fake an ICMP error packet than a TCP RST one, because the 
latter must be acceptable according to the receiver's window too.

Maybe the best were to add the code default disabled.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
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

Re: conntrack: ICMP type 3 code 3 responses should break TCP connections

[Israel G. Lugo]

Hi,

On 09/13/2011 12:49 PM, Jozsef Kadlecsik wrote:
> Yes, at present ICMP(v6) error codes does not terminate TCP connections in 
> conntrack. The problem with acting at receiving ICMP error codes is that 
> it's easier to fake an ICMP error packet than a TCP RST one, because the 
> latter must be acceptable according to the receiver's window too.
>

I hadn't thought of that; you are correct of course. It might be a bad
idea to enable this for all cases, out of the box. Still, it think it
would be good for the option to be available. It could be disabled by
default, as you suggested, with a new switch --match state
--honor-icmp-errors or something.

I believe this would also make sense for UDP state tracking (perhaps
even more so than for TCP, since UDP has no receive window). I don't
have the data in front of me now, but I'm pretty sure I saw UDP sessions
in UNREPLIED state on my router, although the host had replied with an
ICMP type 3, code 3. Of course, the UDP timer is usually quite short,
but it wouldn't hurt to have the _option_ to honor ICMP errors, as
stated above.

Best regards,
Israel G. Lugo