[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: no "flags x"? [CVS: cvs.openbsd.org: src]
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: no "flags x"? [CVS: cvs.openbsd.org: src]
- From: "Denis A. Doroshenko" <d_(_dot_)_doroshenko_(_at_)_omnitel_(_dot_)_net>
- Date: Mon, 28 Oct 2002 11:31:05 +0200
- Mail-followup-to: misc_(_at_)_openbsd_(_dot_)_org
On Mon, Oct 28, 2002 at 09:25:52AM +0100, Camiel Dobbelaar wrote:
> On Mon, 28 Oct 2002, Denis A. Doroshenko wrote:
> > well, is this really good? when i used "flags S" that was indeed "the
> > only SYN, no other flags". how do i do it now, after this change?
> pass in on on lo0 proto tcp from any to any flags $S
yeah, that nicy pf.conf preprocessing! no quarter for missing this.
> There, the rule is only one char longer. :-)
nope, it is strlen("S=\"S/FSRPAUEW\"") + strlen("\n") + 1 char longer :-P
> The bottomline is that 'flags S' is bad, if you want to be a good netizen.
> It breaks ECN for example.
ok, i see the point. this could be just added to a man page, and the
syntax left. there could be even "good" examples, encouraging be a goot
OTOH (a little OT perhaps), that ECN stuff itself smells weird, though.
the usage of pour TOS field (what is that it wasn't for?) etc. then again,
does packet filter check for ECN-Echo and Congestion Window Reduced
flags from TCP header to match the TOS bits ECT/CE? does pf do that
checks, keeping in mind that "messy" ECN stuff...
"Because of the unstable history of the TOS octet, the use of the ECN
field as specified in this document cannot be guaranteed to be
backwards compatible with all past uses of these two bits."
"There is the question of why we chose to have the TCP sending the SYN
set two ECN-related flags in the Reserved field of the TCP header for
the SYN packet, while the responding TCP sending the SYN-ACK sets
only one ECN-related flag in the SYN-ACK packet. This asymmetry is
necessary for the robust negotiation of ECN-capability with deployed
TCP implementations. There exists at least one TCP implementation in
which TCP receivers set the Reserved field of the TCP header in ACK
packets (and hence the SYN-ACK) simply to reflect the Reserved field
of the TCP header in the received data packet."
do you feel comfortable when you read the RFC (i'm reading RFC 2481),
for example sections 9 and 19?
> This change actually makes people think which flags _out of which_ they
> want to allow. I always use 'S/SAFR' myself.
may be you are right. no compatibility, just shake the brains! they
could get a little fat as the time goes by...
Denis A. Doroshenko, GPRS engineer, d_(_dot_)_doroshenko_(_at_)_omnitel_(_dot_)_net, +37069863486
Omnitel Ltd., Muitines Str. 35, LT-2600 Vilnius, Lithuania; www.omnitel.lt
Visit your host, monkey.org