Re: Ambiguities in TCP/IP - firewall bypassing

["Alan DeKok" <aland () ox org>]

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
> > packet.
>
>   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
treat it.

  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
security problems.

  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?

  Alan DeKok.