Re: flags S/SA vs flags S

[Chris Kuethe <ckuethe@ualberta.ca>]

On Tue, 23 Jul 2002, Otto Moerbeek wrote:

> So the Best flag for the state creating rule would be S/SAFR, like kj
> suggested? Ignoring P, U, E and W and any future flags that may pop up?

where would these extra flags come from? the tcp flags are the 13th
byte of the header. end of story. maybe in future someone will have a
Great Plan(tm) for tcp *options* and maybe one day, packet filters
will look at tcp options. but not right now.

i'd say so. let's think about what the flags mean (simplified version):

S	request to start a connection

A	acknowledge something (including a connection request). if
	the ack bit is set on a new connection, someone might be
	trying to fly something by a stupider packet filter. you
	want to filter on this flag to see that it isn't part of
	a connection request.

F	end a connection. specifically "i have nothing more to say"
	SF can be thought of as "i want to talk but have nothing to
	say" and those who say it can be ignored. you want to filter
	on this flag to see that it isn't part of a connection request.

R	reset or refusal of connection. SR approximates answering a
	phonecall by hanging up. doesn't really make sense does it.
	you want to filter on this flag to see that it isn't part of
	a connection request.

P	push this up the stack ASAP. no buffering. this is used by
	telnet or ssh to cause the payload to appear to the application
	right away. if you tcpdump an ssh session, you will see that
	even a single character will cause a tcp segment to be sent
	and acknowledged. when i ssh between two -current machines,
	they do not set the push flag during the handshake, but after
	those first three packets, push is set. i guess that makes
	sense, because until that handshake is complete, there is no
	connection to push data through, is there. block it and see
	what happens, i bet it's safe to block.

U	"Urgent data should take precedence over other data. For
	example, a Ctrl-C to terminate a FTP download." that's what
	an article on oreilleynet says. and indeed, cancelling an
	ftp download does set the urgent bit on the control channel.
	i can't see why you'd want to set this on connection setup...

so yes, you could allow S/UAPRSF (that's the real order) but there may
be things that you want to talk to that use the ECN bits and U and P.
S/SAFR will do what you want.

if you don't feel like learning to read packet dumps, you can go look
at ports/net/tcpshow - it does a decent job of dumping the packet
header, but does not yet seem to grok ecn bits.

> Well, I browsed through the 3.1 IP sources and found quite some ECN
> related stuff, which is enabled by default. So I had the impression that
> there is at least some ECN support in 3.1.

it couldn't have been very complete, since ecn didn't seem to officially
go in until revision 1.111 of sys/netinet/tcp_input.c (openbsd 3.1 was
revision 1.110) and revision 1.50 of sys/netinet/tcp_output.c (openbsd 3.1
Was revision 1.48). these were low-hanging fruit - use cvsweb if you want
to find all the changes.

-- 
Chris Kuethe, GCIA CISSP: Secure Systems Specialist - U of A CNS
      office: 157 General Services Bldg.    +1.780.492.8135
              chris.kuethe@[pyxis.cns.]ualberta.ca

No trees were destroyed in the sending of this contaminant free message; we
do concede a significant number of electrons may have been inconvenienced.