[prev in list] [next in list] [prev in thread] [next in thread] 

List:       best-of-security
Subject:    Sign bits in IP fragmentation
From:       Julian Assange <proff () suburbia ! net>
Date:       1995-08-03 10:51:59
[Download RAW message or body]

Forwarded message:
>From firewalls-owner@GreatCircle.COM Tue Aug  1 10:09:06 1995
Message-Id: <199507311259.FAA28868@miles.greatcircle.com>
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Misbehaving IP and firewalling.
To: Firewalls@GreatCircle.COM (Firewalls Mailing List)
Date: Mon, 31 Jul 1995 22:55:00 +1000 (EST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 887       
Sender: firewalls-owner@GreatCircle.COM
Precedence: bulk


In RFC 791[1], it mentions that one of the "flags" (bit 0) next to the
fragmentation offset is reserved is and must be 0.

In some simple tests, I've found that:

* some IP firwall software assumes that the a fragment offset
  value is amongst the bits in 0x9fff (the one's complement of
  the "dont fragment" and "more fragments" fields)

* routers and unix hosts dont seem to care if it is 0 or not and
  will pass them through.

...I'm not sure who to blame - they're both doing the wrong thing :-)

When is the next TCP/IP bakeoff ?  Can we have a firwall (not proxy based)
bakeoff one too ? :-)

The danger here is that if it is set, 0x8000 is a non-zero fragment (as
the filter sees it) so obviously there is no port info, but your unix
box realises what is going on and turns it into 0x0000.  Voila 8-)

Anyone ever see one of these packets ? :)

darren
[1] Section 3.1, page 13

[prev in list] [next in list] [prev in thread] [next in thread]