mailing list archives
Re: Ambiguities in TCP/IP - firewall bypassing
From: "Alan DeKok" <aland () ox org>
Date: Fri, 18 Oct 2002 17:06:23 -0400
Benjamin Krueger <benjamin () seattlefenix net> wrote:
RFC 1025 (TCP and IP bake-off) has the following text:
10 points for correctly being able to process a "Kamikaze"
packet (AKA nastygram, christmas tree packet, lamp test
segment, et al.). That is, correctly handle a segment with
the maximum combination of features at once (e.g., a SYN URG
PUSH FIN segment with options and data).
But it doesn't define what it means by "correctly handle" such a
Identify what the packet should be, and treat it as such? If that is
the correct way to handle these packets, then these stacks are correct.
So... what should the packet be? As I said, the spec is ambiguous.
If you don't know what the packet is, you obviously don't know how to
Sure, the spec *says* to treat packets with the SYN flag in a
certain way. I'm not arguing with that. What I'm arguing with is the
concept that because the spec is MISSING text on what to do in other
situations, that we know what to do in those situations.
The spec is silent on the use of ambiguous or contradictory flags
(SYN+FIN). So what happens when such a packet is received can only be
described as "implementation defined."
This is not the way to have a secure, or inter-operable protocol.
The TCP state machine diagram has labels naming the flags on
transitions from 'listen' to 'syn received', but it's silent on the
topic of which flags are NOT allowed.
It does, however, consistantly refer to packets as "Syn" or "SynAck"
or "Fin" packets, suggesting that only a specific flag or combination
of flags should be used during the connection.
So SYN+URG is disallowed. But to me, that combination seems
reasonable. So my implementation may not inter-operate with yours.
At the least, we're making different assumptions, which leads to
As I said, the spec is ambiguous.
One could also make a case for continuing to abide by the cardinal
rule "Be permissive in what you accept, and strict in what you send".
Tough call, but its difficult to justify describing stacks that are
permissive as "highly bogus" or "lazy" given that being permissive in
what you accept is an established notion.
Well, at least I didn't say that.
I believe that all of the implementations you named are "compliant"
with the ambiguous TCP specification.
Compliant by the letter, if questionably in spirit. I'm not aware of any
tcp client systems that would send SynFin in the real world, so a stack
that responded with RST could arguably be "more" correct (for example).
<g> I may believe otherwise. Who's to say what's compliant, if the
definition of "compliance" isn't written down anywhere?
Re: Ambiguities in TCP/IP - firewall bypassing Florian Weimer (Oct 19)
Re: Ambiguities in TCP/IP - firewall bypassing David Wagner (Oct 19)
RE: Ambiguities in TCP/IP - firewall bypassing Ofir Arkin (Oct 22)