TCP Loopback Connections with the Same Src/Dest Port

[Fernando Gont]

Hi, Matt,

Please heck this IETF Internet-Draft:
<http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-00>

Some comments:

On 07/17/2013 01:08 PM, Matt Miller wrote:
> 
> Some questions we had:
> 
> - Has anyone else ever seen these same src/dest address/port TCP
> connections created?  Does anyone know of a legitimate reason why they
> should be allowed?

Could be used for TCP-based IPC.



> - If there are no known use cases for this type of connection, does
> anyone have more context/insight on the design here: should this type
> of inpcb creation be prevented in the kernel or is it the
> application's responsibility to ensure it never creates this type of
> socket?

It should be allowed -- although some systems have been known to fail to
handle this scenarios gracefully.



> For those interested, more details of the issue seen follow.  The
> connection seems to get stuck in swi_net sending and receiving pure
> FIN/ACKs to itself:
> 
> #12 0xffffffff804372ce in ip_output (m=0xffffff0003ccf300,
> opt=<optimized out>, ro=0xffffff8020c2b6a0, flags=0, imo=0x0,
> inp=0xffffff0019933968) at ../../../../sys/netinet/ip_output.c
> #13 0xffffffff804423dc in tcp_output (tp=0xffffff0019de2370) at
> ../../../../sys/netinet/tcp_output.c
> #14 0xffffffff8043ef5d in tcp_do_segment (m=0xffffff0019af1200,
> th=0x100200, so=0xffffff011ac59570, tp=0xffffff0019de2370,
> drop_hdrlen=52, tlen=0, iptos=0 '\000', ti_locked=3) at
> ../../../../sys/netinet/tcp_input.c
> #15 0xffffffff80440311 in tcp_input (m=0xffffff0019af1200,
> off0=<optimized out>) at ../../../../sys/netinet/tcp_input.c
> #16 0xffffffff8043530b in ip_input (m=0xffffff0019af1200) at
> ../../../../sys/netinet/ip_input.c
> #17 0xffffffff8040889f in netisr_process_workstream_proto
> (proto=<optimized out>, nwsp=<optimized out>) at
> ../../../../sys/net/netisr.c
> #18 swi_net (arg=0xffffffff80f59800) at ../../../../sys/net/netisr.c
> 
> swi_net() just continues in this loop, ad nauseam:
[...]

This results in a packet war, right? (one segment sent after another,
with no delays in between).


> I've noticed that we don't yet have this patch in our code:
> 
> http://svnweb.freebsd.org/base?view=revision&revision=239672
> 
> Which seems like it could be relevant here to the general case of both
> ends of the connection entering FIN_WAIT_1 at the same time and
> sending FIN/ACKs repeatedly (though our connections are a bizarre case
> of this where both ends of the connection are actually the same
> connection).

Last time I checked, FreeBSD was handlind this case properly... so this
is probably the result of the patch you're referring to.

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1