netdev - GTSM and TCP accept problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100814214634.24a87715@s6510>
Date:	Sat, 14 Aug 2010 21:46:34 -0400
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Eric Dumazet <dada1@...mosbay.com>,
	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	netdev@...r.kernel.org
Subject: GTSM and TCP accept problem

The implementation of Generalized TTL Security has a problem
on the TCP accept side. Since there can be different number of
hops for each peer, the listener ends up doing

   socket
   bind
   set TTL to 255
   listen
   while (nfd = accept(peer)) {
     info = lookup(peer)
     set MINTTL to 255 - info->ttl_hops


The problem is that a rogue peer can still do three way
handshake causing the accept to succeed. But the rogue will
leave a stuck connection that will then have to timeout.

The only ways I have come up to deal with this are:
   * have short timeout on initial data (recycle faster)
   * push peer;MINTTL table down into kernel (per socket)
   * have BGP do this through iptables which is a non-starter
     for a general application that needs to run on BSD, and
     would mess up existing firewall rules.

Ideas welcome..
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html