Suppress / delay SYN-ACK

Suppress / delay SYN-ACK

[Martin Schiller]

Hi!

I'm searching for a solution to suppress / delay the SYN-ACK packet of a
listening server (-application) until he has decided (e.g. analysed the
requesting ip-address or checked if the corresponding other end of a
connection is available) if he wants to accept the connect request of the
client. If not, it should be possible to reject the connect request.

My idea is to add two ioctl's:
	- One to set the listening socket into "delay_synack" mode.
	- And one to send the synack packet, if the connection should be
accepted.

If the "delay_synack" mode is not enabled, the connection should just work
as usual.

I had a look at the tcp/ipv4 stack for a while and have found out, that this
three-way-handshake is already done before anything comes up to user-space
when I am doing a call to accept(). So I think it wouldn't be possible to
add this feature with "a little hack".

Does anybody have any hints for me where I should start to work?

Regards,
Martin Schiller

Re: Suppress / delay SYN-ACK

[Eric Dumazet]

On Thursday 12 October 2006 10:08, Martin Schiller wrote:
> Hi!
>
> I'm searching for a solution to suppress / delay the SYN-ACK packet of a
> listening server (-application) until he has decided (e.g. analysed the
> requesting ip-address or checked if the corresponding other end of a
> connection is available) if he wants to accept the connect request of the
> client. If not, it should be possible to reject the connect request.
>
> My idea is to add two ioctl's:
> 	- One to set the listening socket into "delay_synack" mode.
> 	- And one to send the synack packet, if the connection should be
> accepted.
>
> If the "delay_synack" mode is not enabled, the connection should just work
> as usual.
>
> I had a look at the tcp/ipv4 stack for a while and have found out, that
> this three-way-handshake is already done before anything comes up to
> user-space when I am doing a call to accept(). So I think it wouldn't be
> possible to add this feature with "a little hack".
>

Well, it is already possible to delay the 'third packet' of an outgoing 
connection with a litle hack. But AFAIK not the SYNACK of incoming 
connection. It could be cool. Maybe some new syscalls are needed:

int syn_recv(int socklisten, ...);
/* give to user app the SYN packet */
int syn_ack(int socklisten, ...);
/* User app has the ability to ask kernel tcp stack to :
    DROP this packet.
    REJECT the attempt
    ACCEPT the attempt (sending a SYN/ACK)
*/

Maybe NETLINK (netfilter) is able to meet your need.

> Does anybody have any hints for me where I should start to work?
>
> Regards,
> Martin Schiller

RE: Suppress / delay SYN-ACK

[Martin Schiller]

On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote:
>
> Well, it is already possible to delay the 'third packet' of an
> outgoing connection with a litle hack. But AFAIK not the SYNACK of
> incoming connection. It could be cool. Maybe some new syscalls are
> needed:   
> 
> int syn_recv(int socklisten, ...);
> /* give to user app the SYN packet */
> int syn_ack(int socklisten, ...);
> /* User app has the ability to ask kernel tcp stack to :
>     DROP this packet.
>     REJECT the attempt
>     ACCEPT the attempt (sending a SYN/ACK) */
> 

So, when do you mean the user-space application should run this syscalls?
After the call to listen()?

Another problem with this solution might be, that I don't want to block the
listening socket with the processing of one request, because there could be
a lot of simultaneous requests. 

Re: Suppress / delay SYN-ACK

[Evgeniy Polyakov]

On Thu, Oct 12, 2006 at 12:13:26PM +0200, Martin Schiller (mschiller@tdt.de) wrote:
> On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote:
> >
> > Well, it is already possible to delay the 'third packet' of an
> > outgoing connection with a litle hack. But AFAIK not the SYNACK of
> > incoming connection. It could be cool. Maybe some new syscalls are
> > needed:   
> > 
> > int syn_recv(int socklisten, ...);
> > /* give to user app the SYN packet */
> > int syn_ack(int socklisten, ...);
> > /* User app has the ability to ask kernel tcp stack to :
> >     DROP this packet.
> >     REJECT the attempt
> >     ACCEPT the attempt (sending a SYN/ACK) */
> > 
> 
> So, when do you mean the user-space application should run this syscalls?
> After the call to listen()?
> 
> Another problem with this solution might be, that I don't want to block the
> listening socket with the processing of one request, because there could be
> a lot of simultaneous requests. 

You should break your decision into per state change transformations.
I think it is possible with either conntrack or netlink module Samir
Bellabes <sbellabes_mandriva.com> creates (Network Events Connector
subject) or even using syncookie algo changes.

But it will drastically change your server performance...

-- 
	Evgeniy Polyakov

Re: Suppress / delay SYN-ACK

[Eric Dumazet]

On Thursday 12 October 2006 12:31, Evgeniy Polyakov wrote:
> On Thu, Oct 12, 2006 at 12:13:26PM +0200, Martin Schiller (mschiller@tdt.de) 
wrote:
> > On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote:
> > > Well, it is already possible to delay the 'third packet' of an
> > > outgoing connection with a litle hack. But AFAIK not the SYNACK of
> > > incoming connection. It could be cool. Maybe some new syscalls are
> > > needed:
> > >
> > > int syn_recv(int socklisten, ...);
> > > /* give to user app the SYN packet */
> > > int syn_ack(int socklisten, ...);
> > > /* User app has the ability to ask kernel tcp stack to :
> > >     DROP this packet.
> > >     REJECT the attempt
> > >     ACCEPT the attempt (sending a SYN/ACK) */
> >
> > So, when do you mean the user-space application should run this syscalls?
> > After the call to listen()?
> >
> > Another problem with this solution might be, that I don't want to block
> > the listening socket with the processing of one request, because there
> > could be a lot of simultaneous requests.
>
> You should break your decision into per state change transformations.
> I think it is possible with either conntrack or netlink module Samir
> Bellabes <sbellabes_mandriva.com> creates (Network Events Connector
> subject) or even using syncookie algo changes.

Hum.. they are some cases where conntrack is not an option (way too expensive 
if your server handle XXX.XXX concurrent tcp streams)

>
> But it will drastically change your server performance...

Sure, at least its capacity to answer to SYN packets (session establishment 
should be slower, unless the thread receiving/handling SYN packets has 
realtime scheduling)

Eric

Re: Suppress / delay SYN-ACK

[Evgeniy Polyakov]

On Thu, Oct 12, 2006 at 12:39:30PM +0200, Eric Dumazet (dada1@cosmosbay.com) wrote:
> > You should break your decision into per state change transformations.
> > I think it is possible with either conntrack or netlink module Samir
> > Bellabes <sbellabes_mandriva.com> creates (Network Events Connector
> > subject) or even using syncookie algo changes.
> 
> Hum.. they are some cases where conntrack is not an option (way too expensive 
> if your server handle XXX.XXX concurrent tcp streams)

I think any netlink related work here can not be used for any kind of
high performance setup - it will be too slow to send/receive one or more
messages per state change for each new connection...

> > But it will drastically change your server performance...
> 
> Sure, at least its capacity to answer to SYN packets (session establishment 
> should be slower, unless the thread receiving/handling SYN packets has 
> realtime scheduling)

Maybe it will be better to create some more complex protocol which will
collect data before sending netlink message, or just use a procfs file
or syscall/ioctl/socket option.

> Eric

-- 
	Evgeniy Polyakov

Re: Suppress / delay SYN-ACK

[Eric Dumazet]

On Thursday 12 October 2006 12:13, Martin Schiller wrote:
> On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote:
> > Well, it is already possible to delay the 'third packet' of an
> > outgoing connection with a litle hack. But AFAIK not the SYNACK of
> > incoming connection. It could be cool. Maybe some new syscalls are
> > needed:
> >
> > int syn_recv(int socklisten, ...);
> > /* give to user app the SYN packet */
> > int syn_ack(int socklisten, ...);
> > /* User app has the ability to ask kernel tcp stack to :
> >     DROP this packet.
> >     REJECT the attempt
> >     ACCEPT the attempt (sending a SYN/ACK) */
>
> So, when do you mean the user-space application should run this syscalls?
> After the call to listen()?
>

Exactly like when you call accept() on a non blocking listening socket.

If your application did asked to received notification of SYN packets, it 
should be prepared to call accept() (to be notified of fully established 
connections) and/or syn_recv() (to be notified of SYN packets)

So when poll()/select()/epoll() tells your socklisten has available events, 
your application would have to call both accept() and syn_recv() in a loop to 
empty all awaiting events.

> Another problem with this solution might be, that I don't want to block the
> listening socket with the processing of one request, because there could be
> a lot of simultaneous requests.

Yes I can imagine.

Re: Suppress / delay SYN-ACK

[Rick Jones]

Martin Schiller wrote:
> Hi!
> 
> I'm searching for a solution to suppress / delay the SYN-ACK packet of a
> listening server (-application) until he has decided (e.g. analysed the
> requesting ip-address or checked if the corresponding other end of a
> connection is available) if he wants to accept the connect request of the
> client. If not, it should be possible to reject the connect request.

How often do you expect the incomming call to be rejected?  I suspect that would 
have a significant effect on whether the whole thing is worthwhile.

rick jones

Re: Suppress / delay SYN-ACK

[Caitlin Bestler]

On 10/12/06, Rick Jones <rick.jones2@hp.com> wrote:
> Martin Schiller wrote:
> > Hi!
> >
> > I'm searching for a solution to suppress / delay the SYN-ACK packet of a
> > listening server (-application) until he has decided (e.g. analysed the
> > requesting ip-address or checked if the corresponding other end of a
> > connection is available) if he wants to accept the connect request of the
> > client. If not, it should be possible to reject the connect request.
>
> How often do you expect the incomming call to be rejected?  I suspect that would
> have a significant effect on whether the whole thing is worthwhile.
>
> rick jones


More to the point, on what basis would the application be rejecting a
connection request based solely on the SYN?

There are only two pieces of information available: the remote IP
address and port, and the total number of pending requests. The
latter is already addressed through the backlog size, and netfilter
rules can already be used to reject based on IP address.

That would seem to limit the usefullness to scenarios where a given
remote IP address *might* be accepted based on total traffic load,
number of other connections from the same IP address, etc.  If
*all* requests from that IP address are going to be rejected, why
not use netfilter?

Re: Suppress / delay SYN-ACK

[jamal]

On Thu, 2006-12-10 at 14:58 -0700, Caitlin Bestler wrote:

> That would seem to limit the usefullness to scenarios where a given
> remote IP address *might* be accepted based on total traffic load,
> number of other connections from the same IP address, etc.  If
> *all* requests from that IP address are going to be rejected, why
> not use netfilter?

Netfilter or ingress tc may both work; 
I have a feeling that the poster needs to consult some policy+state in
the application first which is more complex than what rate control or
number of connections provide (DOS detection?)- in which case, theyd
have to write a netfilter target.

cheers,
jamal

Re: Suppress / delay SYN-ACK

[Rick Jones]

> More to the point, on what basis would the application be rejecting a
> connection request based solely on the SYN?

True, it isn't like there would suddenly be any call user data as in XTI/TLI.

> There are only two pieces of information available: the remote IP
> address and port, and the total number of pending requests. The
> latter is already addressed through the backlog size, and netfilter
> rules can already be used to reject based on IP address.

It would though allow an application to have an even more restricted set of 
allowed IP's than was set in netfilter.  Rather like allowing the application to 
set socket buffer sizes rather than relying on the system's default.

rick jones

Re: Suppress / delay SYN-ACK

[Stephen Hemminger]

On Thu, 12 Oct 2006 15:54:49 -0700
Rick Jones <rick.jones2@hp.com> wrote:

> > More to the point, on what basis would the application be rejecting a
> > connection request based solely on the SYN?
> 
> True, it isn't like there would suddenly be any call user data as in XTI/TLI.
> 
> > There are only two pieces of information available: the remote IP
> > address and port, and the total number of pending requests. The
> > latter is already addressed through the backlog size, and netfilter
> > rules can already be used to reject based on IP address.
> 
> It would though allow an application to have an even more restricted set of 
> allowed IP's than was set in netfilter.  Rather like allowing the application to 
> set socket buffer sizes rather than relying on the system's default.
>

Some version of BSD sockets had this behaviour, perhaps you should use
the same model.  It was some socket option, I can't remember; what ever
it wasn't widely adopted. Nothing says you can't just use shutdown() to
force a RST on the addresses you don't want to talk to.

Re: Suppress / delay SYN-ACK

[Eric Dumazet]

Rick Jones a écrit :
>> More to the point, on what basis would the application be rejecting a
>> connection request based solely on the SYN?
> 
> True, it isn't like there would suddenly be any call user data as in 
> XTI/TLI.

DATA payload could be included in the SYN packet. TCP specs allow this AFAIK.

About iptables rules added on the fly by an application that want to protect 
its listen queue from random sources of 'blacklisted' peers, this has the 
limitation of granting sufficient rights to the user running the application.

Eric

Re: Suppress / delay SYN-ACK

[Rick Jones]

Eric Dumazet wrote:
> Rick Jones a écrit :
> 
>>> More to the point, on what basis would the application be rejecting a
>>> connection request based solely on the SYN?
>>
>>
>> True, it isn't like there would suddenly be any call user data as in 
>> XTI/TLI.
> 
> 
> DATA payload could be included in the SYN packet. TCP specs allow this 
> AFAIK.

Yes, but it isn't supposed to be delivered until the 3-way handshake is complete 
right?

rick jones

Re: Suppress / delay SYN-ACK

[Eric Dumazet]

Rick Jones a écrit :
> Eric Dumazet wrote:
>> Rick Jones a écrit :
>>
>>>> More to the point, on what basis would the application be rejecting a
>>>> connection request based solely on the SYN?
>>>
>>>
>>> True, it isn't like there would suddenly be any call user data as in 
>>> XTI/TLI.
>>
>>
>> DATA payload could be included in the SYN packet. TCP specs allow this 
>> AFAIK.
> 
> Yes, but it isn't supposed to be delivered until the 3-way handshake is 
> complete right?

Are you speaking of 20 years old BSD API ? :)

Martin, I played with libnetfilter_queue 
(http://www.netfilter.org/projects/libnetfilter_queue/index.html)

With this single iptables rules, I was able to do what you want : transmit the 
SYN message to a user application, that may DROP this packet or let it pass 
normal TCP stack.

iptables -A INPUT -p tcp --dport 333 --syn -j QUEUE

Then hack nfqnl_test.c to meet your needs (see nfq_set_verdict(), 
nfq_get_payload())

Be prepared to receive the 'same SYN' several time if your X.25 call attempt 
is too long.

(You have to be root unfortunatly)

Eric

Re: Suppress / delay SYN-ACK

[Rick Jones]

>>> DATA payload could be included in the SYN packet. TCP specs allow 
>>> this AFAIK.
>> Yes, but it isn't supposed to be delivered until the 3-way handshake 
>> is complete right?
> Are you speaking of 20 years old BSD API ? :)

Nope - the bits in the RFCs about data not being delivered until the ISN's are 
validated.  I may have some of the timing a bit wrong though.

rick jones

RE: Suppress / delay SYN-ACK

[Martin Schiller]

On Friday, October 13, 2006 10:14 PM, Eric Dumazet wrote:
>
> Martin, I played with libnetfilter_queue
> (http://www.netfilter.org/projects/libnetfilter_queue/index.html)
> 
> With this single iptables rules, I was able to do what you want :
> transmit the SYN message to a user application, that may DROP this
> packet or let it pass normal TCP stack.  
> 
> iptables -A INPUT -p tcp --dport 333 --syn -j QUEUE
> 
> Then hack nfqnl_test.c to meet your needs (see nfq_set_verdict(),
> nfq_get_payload())
> 
> Be prepared to receive the 'same SYN' several time if your X.25 call
> attempt is too long. 
> 
> (You have to be root unfortunatly)
> 
> Eric

Thanks, this sounds very interesting. I will have a closer look at that.

Martin

Re: Suppress / delay SYN-ACK

[Stephen J. Bevan]

Caitlin Bestler writes:
 > More to the point, on what basis would the application be rejecting a
 > connection request based solely on the SYN?

Perhaps not the reason that Martin is interested in but ...

Say you are writing a transparent proxy i.e. when a TCP connection is
made through the box, rather than forwarding the TCP SYN, it is
delivered locally where it accepted and then the proxy makes a
separate TCP connection to original IP address.  Thus all traffic
flows through a user-space proxy that can cache, log, virus scan,
... etc. the traffic.  Say also that the proxy is for a protocol that
can mediate peer<->peer connections via a server (e.g. most IM
protocols).  Furher still assume that the client has the property that
if while trying to establish a peer<->peer connection it will back off
and use the server if it does not manage to establish the peer<->peer
TCP connection but if it does establish the connection then it will
not back off to use the server.  Thus if a client is behind the
transparent proxy the proxy terminates the TCP connection locally and
at that point the client thinks it has connected to the peer even
though the proxy has yet to establish a connection to the peer.

Should the proxy fail to do so all it can do is drop the
client<->proxy connection at which point the client does not connect
via the server and the user of the client is not happy since if the
proxy wasn't there everything would have worked just fine.  So, if the
proxy could delay the SYN/ACK until it has determined whether it can
really connect to the IP address in the SYN, then it can decide
whether to SYN/ACK or just not respond.

Of course, the much simpler solution is to fix the client program so
that it will still back off to the server even if it does manage to
make a TCP connection.  However, fixing other people's software is
easier said than done.  So if you are trying to $ell a tranparent
proxy solution, you need to handle it somehow.  Delayed SYN/ACK is one
such way, though not necessarily the best way.

RE: Suppress / delay SYN-ACK

[Martin Schiller]

On Friday, October 13, 2006 7:42 AM, Stephen J. Bevan wrote:

> Say you are writing a transparent proxy i.e. when a TCP connection is
> made through the box, rather than forwarding the TCP SYN, it is
> delivered locally where it accepted and then the proxy makes a
> separate TCP connection to original IP address.  Thus all traffic
> flows through a user-space proxy that can cache, log, virus scan, ...
> etc. the traffic.  Say also that the proxy is for a protocol that can
> mediate peer<->peer connections via a server (e.g. most IM
> protocols).  Furher still assume that the client has the property
> that if while trying to establish a peer<->peer connection it will
> back off and use the server if it does not manage to establish the
> peer<->peer TCP connection but if it does establish the connection
> then it will not back off to use the server.  Thus if a client is
> behind the transparent proxy the proxy terminates the TCP connection
> locally and at that point the client thinks it has connected to the
> peer even though the proxy has yet to establish a connection to the
> peer.               
> 
> Should the proxy fail to do so all it can do is drop the
> client<->proxy connection at which point the client does not connect
> via the server and the user of the client is not happy since if the
> proxy wasn't there everything would have worked just fine.  So, if
> the proxy could delay the SYN/ACK until it has determined whether it
> can really connect to the IP address in the SYN, then it can decide
> whether to SYN/ACK or just not respond.      
> 
> Of course, the much simpler solution is to fix the client program so
> that it will still back off to the server even if it does manage to
> make a TCP connection.  However, fixing other people's software is
> easier said than done.  So if you are trying to $ell a tranparent
> proxy solution, you need to handle it somehow.  Delayed SYN/ACK is
> one such way, though not necessarily the best way. -    
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html  

That's nearly exactly what our situation is:

The machine on which the SYN-ACK-feature should be implemented is a
TCP-to-X.25 Gateway. There are really stupid TCP terminals out there which
connects to the Gateway and simply start sending their data after the
connection between them and the Gateway is established.

The Gateway otherwise has to check its internal routing-table, which X.25
Number should be called for the requesting TCP terminal and establish this
X.25 connection.

And now here is the point:
If, why ever, the X.25 connection can't be established, the TCP-connection
to the terminal has to be closed, or even better: NOT been established at
all, so that the terminal can't send any data.

So if you ask me, how often the connections should be rejected, i have to
say: "Hopefully never", but so long as this stupid terminals will be very
confused if the connection is firstly established and than suddenly closed,
I think I can't resign this feature.

Re: Suppress / delay SYN-ACK

[Lennert Buytenhek]

On Thu, Oct 12, 2006 at 10:08:53AM +0200, Martin Schiller wrote:

> I'm searching for a solution to suppress / delay the SYN-ACK packet of a
> listening server (-application) until he has decided (e.g. analysed the
> requesting ip-address or checked if the corresponding other end of a
> connection is available) if he wants to accept the connect request of the
> client. If not, it should be possible to reject the connect request.

I wrote something like this a couple of years ago:

	http://marc.theaimsgroup.com/?l=linux-netdev&m=103666165629419&w=2
	http://marc.theaimsgroup.com/?l=linux-netdev&m=106089519611631&w=2

There wasn't a whole lot of external interest, and my need for it
disappeared, so I never really finished it, and there's a couple of
unfixed bugs,


cheers,
Lennert

RE: Suppress / delay SYN-ACK

[Martin Schiller]

On Monday, October 16, 2006 9:02 AM, Lennert Buytenhek wrote:
> 
> I wrote something like this a couple of years ago:
> 
> 	http://marc.theaimsgroup.com/?l=linux-netdev&m=103666165629419&w=2
> 	http://marc.theaimsgroup.com/?l=linux-netdev&m=106089519611631&w=2
> 
> There wasn't a whole lot of external interest, and my need for it
> disappeared, so I never really finished it, and there's a couple of
> unfixed bugs,  
> 

Lennert's patch does nearly exactly the way how I tried to do it earlier by
myself and after porting the patch to kernel 2.6.15.4 and 2.6.11.12, which I
am currently using, it works great.

The only change I've made is that I don't want to send the SYN-ACK only with
the first write() on the socket, because in my application the requesting
client is also the one who starts sending data. So I introduced an ioctl()
which simply runs tcp_confirm() to send the SYN-ACK.

So...
Thanks a lot to everyone who gave me hints and tips to solve my problem.

Martin

Re: Suppress / delay SYN-ACK

[Eric Dumazet]

On Tuesday 17 October 2006 14:04, Martin Schiller wrote:
> On Monday, October 16, 2006 9:02 AM, Lennert Buytenhek wrote:
> > I wrote something like this a couple of years ago:
> >
> > 	http://marc.theaimsgroup.com/?l=linux-netdev&m=103666165629419&w=2
> > 	http://marc.theaimsgroup.com/?l=linux-netdev&m=106089519611631&w=2
> >
> > There wasn't a whole lot of external interest, and my need for it
> > disappeared, so I never really finished it, and there's a couple of
> > unfixed bugs,
>
> Lennert's patch does nearly exactly the way how I tried to do it earlier by
> myself and after porting the patch to kernel 2.6.15.4 and 2.6.11.12, which
> I am currently using, it works great.
>
> The only change I've made is that I don't want to send the SYN-ACK only
> with the first write() on the socket, because in my application the
> requesting client is also the one who starts sending data. So I introduced
> an ioctl() which simply runs tcp_confirm() to send the SYN-ACK.


Well, did you solve Lennert problem if the final (third packet of three packet 
TCP establishment handshake) packet is missing ?
It seems no timer will fire and tell you the socket is not usable...

Eric

RE: Suppress / delay SYN-ACK

[Martin Schiller]

On Tuesday, October 17, 2006 2:54 PM, Eric Dumazet wrote:
> 
> Well, did you solve Lennert problem if the final (third packet of
> three packet TCP establishment handshake) packet is missing ? It
> seems no timer will fire and tell you the socket is not usable... 
> 

Sorry, but I don't know what you exactly mean with this problem.

On my first short tests, when I send the SYN-ACK with the ioctl and don't
get an ACK, the first read on the socket returns "-1". So I can see that the
connection is not established and usable.

Martin