GTSM and TCP accept problem

GTSM and TCP accept problem

[Stephen Hemminger]

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..

Re: GTSM and TCP accept problem

[David Miller]

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 14 Aug 2010 21:46:34 -0400

> 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

Surely when creating the initial listening socket we should use the
minimum TTL over the set of peers right?

That surely takes most of the fun out of this problem for the
attacker.

Re: GTSM and TCP accept problem

[Stephen Hemminger]

On Sat, 14 Aug 2010 22:12:58 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Sat, 14 Aug 2010 21:46:34 -0400
> 
> > 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
> 
> Surely when creating the initial listening socket we should use the
> minimum TTL over the set of peers right?
> 
> That surely takes most of the fun out of this problem for the
> attacker.

That only works if all peers are external and using ttl-security.
If any peer is not using ttl-security, then that peer will be
sending with low TTL and the SYN would get dropped.

The real problem goes back to the GTSM RFC assumptions that TTL
security will be done by firewall, not TCP itself.

Re: GTSM and TCP accept problem

[Eric Dumazet]

Le samedi 14 août 2010 à 21:46 -0400, Stephen Hemminger a écrit :
> 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..
> --

Another idea would be to store the TTL of the SYN packet (or third
packet) and let application read it after accept(), allowing it to
reject the connection if it doesnt match expected TTL.

Re: GTSM and TCP accept problem

[Stephen Hemminger]

On Mon, 16 Aug 2010 11:43:45 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Le samedi 14 août 2010 à 21:46 -0400, Stephen Hemminger a écrit :
> > 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..
> > --
> 
> Another idea would be to store the TTL of the SYN packet (or third
> packet) and let application read it after accept(), allowing it to
> reject the connection if it doesnt match expected TTL.

could be in tcp_info?
-- 

Re: GTSM and TCP accept problem

[David Miller]

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 18 Aug 2010 14:39:13 -0700

> On Mon, 16 Aug 2010 11:43:45 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
>> Another idea would be to store the TTL of the SYN packet (or third
>> packet) and let application read it after accept(), allowing it to
>> reject the connection if it doesnt match expected TTL.
> 
> could be in tcp_info?

I'm sure we can squeeze a byte out of there :-)

Re: GTSM and TCP accept problem

[venkatesh natarajan]

David Miller <davem <at> davemloft.net> writes:

> 
> From: Stephen Hemminger <shemminger <at> vyatta.com>
> Date: Wed, 18 Aug 2010 14:39:13 -0700
> 
> > On Mon, 16 Aug 2010 11:43:45 +0200
> > Eric Dumazet <eric.dumazet <at> gmail.com> wrote:
> > 
> >> Another idea would be to store the TTL of the SYN packet (or third
> >> packet) and let application read it after accept(), allowing it to
> >> reject the connection if it doesnt match expected TTL.
> > 
> > could be in tcp_info?
> 
> I'm sure we can squeeze a byte out of there 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


I am facing the same issue with the implementation of GTSM for BGP. Typically 
the outbound TTL value set is 64. With min_ttl implementaion we set the outbound 
TTL value of 255 by default. So all bgp speakers will send out 255 in their 
connect SYN packets. Lets say we configure the min_ttl of 254 on the listen 
socket then it will allow only those peers that are 2 hops away to connect 
(Which is correct for eBGP Peers) but it will also filter out legitimate connect 
SYN packets that come from iBGP peers that are more than 2 hops away (Which I 
feel is a unexpected behavior). 

How can accept check for iBGP peers and not check for the MIN_TTL. I feel this 
could be done only by pushing the iBGP Peer ip-address information to accept so 
that it can bypass MIN_TTL Checks for them.

If I apply the MIN_TTL setsockopt on the accepted socket (Instead of seting it 
on the listen socket) then I open up the port for DOS attack at the tcp level by 
allowing attackers to establish connection and repeatedly..

Have I understood the problem correctly or have gone off-tangent on this.

Thanks
Venks