Re: BARE BYTE UNICODE ENCODING

[nick black <dank () reflexsecurity net>]

On 2004-06-02, Omar Herrera <oherrera () prodigy net mx> wrote:
> Any alert that checks for patterns at application level will trigger
> with ACK packets.

// Pedanticism warning, although the last paragraphs may be considered
// insightful. :)

Unfortunately, as the setting of ACK and SYN flags has nothing to do
with the transmission of payload -- save popular implementation choices
and some history -- despite common misconception.  (From what I can tell;
my knowledge may certainly be and likely is limited.  I'd love comments
from the more experienced on this list).

> SYN packets are only used to initiate the connection
> (three-way-handshake) and therefore have no application payload. ACK

This contradicts a wary interpretation of RFC 793 3.4, and practical
consideration of, say, a high-performance server feeding a high-latency
pipe (a standard banner, etc would be useful to overload into a SYN-ACK).
Also, a stack implementing T/TCP may very well provide API suitable
for standard TCP, embracing a connect + initial send idiom.  A
simultaneous open unacked by one side could plausibly elicit these SYNs.

Stevens raises the issue explicitly in exercise 24.9 of TCPv1, and while
his queuing solution seems incomplete (a runt ACK, drop of the data save
the SYN's allocated sequence number, and possible window advertisement
of 0 seems saner and legal), I'll trust his authority on whether payloads
can piggyback on SYN's.  It's not like a markov/annealment method won't
reach closure on most following transitions if one wants to get really
anal about things.

> packets carry payload (HTTP in this case) and are used to exchange data

Not to be stupidly pedantic, but ACK packets don't "carry data".  ACK is
simply set on all packets save an active open's SYN because a) ACK segments
with 0 byte payloads are not reliably transmitted, b) congestion
avoidance (see tcp's self-clocking, fast retransmit, and fast
recovery) algorithms can key off repeated ACKs, and c) the window
advertisement is based off the ack num.  Certain RST's don't bear ACK,
but what can you really say meaningfully about RST's?

Indeed, blind acks of every receipt vs. the delayed ack requirement of
RFC 1122 both have their benefits, a game of bandwidth + processing vs.
latency.

What's the upshot of all this?  If you wish to specify that "this should
only be tested against TCP payloads", specify that, and design your
signature language so the exact concept is expressible.  The blight of
"flags: A+;" tests permeating snort's rulesets have always struck me as
a misguided attempt to lazily optimize rule evaluation at the expense
of correctness and clarity.  I'd love to be educated otherwise [0].

[0] Even more so, I'd love to see the rigorous profiling determining the
superiority of pre-pruning content matching ops (proportional to payload
length) for generally payloadless [1] SYN packets vs. memory pressures
resulting from the additional aggregate page spillage, cache/register 
loads, etc.

[1] Unless someone's cuckolding your snort box.

These opinions are mine, and not necessarily those of Reflex Security.

-- 
nick black <dank () reflexsecurity com>
"np:  nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo


---------------------------------------------------------------------------

---------------------------------------------------------------------------