[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: Keep state questions
From:       Darren Reed <darrenr () cyber ! com ! au>
Date:       1996-06-05 2:30:10
[Download RAW message or body]

In some mail I received from Nigel Verdon, sie wrote
> 
> Darren,
> 
> If have a few requests/ideas/questions on the keep state functionality.
> 
> 1.  For all connections.  Add an extra option to set the "timeout
>     period" in some "units" to help distinguish between "networks on 
>     the end of a bit of string" and locally connected networks.  Can
>     help spot certain "tampering profiles".  The option would set
> 
>         is->is_age (in ip_state.c)
> 
>     to either a default value or a specific value. The syntax could
>     possibly be extended as below:
> 
>         pass in on le0 proto udp from any to 155.145.32.1 keep state 40

Hmmm...I've already recommended to one person that they set the value to 1
when the connection is closing.  Whilst IP Filter believes the connection
is alive and kicking, it won't time it out.  This was a problem for a web
server (obvious reasons).

If the state is initialised with a packet with the SYN bit set, and only the
SYN bit set, the connection setup has a timeout of 120 (60 seconds) and once
a packet with an ACK is seen, the connection timeout is set to 0 (no timeout)
until an RST or FIN is seen and the timeout is then set to 120.  60 seconds
is, I think, 2*MSL for TCP.

>     For additional control, keep track of sequence numbers and drop the 
>     connection if a wrong sequence number appears.  This could also be a 
>     configurable option - to drop or not to drop.

Hmmm, this almost makes it pointless, except to keep track of current
connections through the firewall...

> 3.  For UDP connections.  Would it be possible to set an additional counter
>     that would state - I expect up to x UDP packets within the timeout
>     period in reply to my UDP request.  This is for situations such as the
>     proposed SNMP v2 bulk request which can potentially send replies in more
>     than 1 UDP packet.

There should be no limit on the number of packets, only how long they have
to get through.  Every time a packet matches, in either direction, the
timeout is reset to 120.

Hope this helps,
darren

[prev in list] [next in list] [prev in thread] [next in thread]