Re: RE: sequence No.

[Jeff Nathan <jeff () wwti com>]

Archive: http://msgs.securepoint.com/ids
FAQ IDS: http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm
FAQ NIDS: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owner () uow edu au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
-----------------------------------------------------------------------------
I've been thinking this over and I'm wondering if some of this isn't
jumping the gun.  Yesterday during a discussion, someone mentioned to me
the one thing we have been overlooking.  That being, bad hardware can
effect all of this!  A broken router between any two end points could
corrupt any portion of the raw byte stream it's looking at.  At a real
nitty gritty level it doesn't really know about IP, etc.. It might
mangle a random byte or even a few bytes such that an overlap could
occur.

Also, to a degree, it bothers me that a border device would be designed
to violate the RFC standard for handling new fragments w/ overlap.  I
understand what you're getting at, and in the case of a gateway device
that does the work of a firewall but through IDS mechanisms, it would of
course make decisions on what traffic got through and what didn't get
through.  I think that ideally, a gateway device that had both firewall
and IDS functionality would defragment everything properly at the
gateway, etc.  A simple border device might handle overlaps but what
about overlaps w/ options? :P

-Jeff

Bill Royds wrote:
> Yes, I was implying that the trade-off would be to ensure headers were canonical but that body could be fragmented.
> This is essentially the level of stateful packet filters anyway. If you are not willing to fully de-fragment the 
> packet (and Marty gave reason why not), then at least ensure that no headers are fragmented. There is no rule that 
> all fragments of a packet have to be the same size, just less than MTU. So one would re-assemble the packet to get 
> the header information (and probably the first bytes of body until MTU) then reject any further packets that are 
> offset into this space.
>   True fragments do not have overlapping offsets, but may come out of order so higher offsets arrive before lower 
> ones.
> To minimise buffers, one would re-assemble the packet until all headers were complete (which might mean some body 
> bytes are present as well), then keep state on completed parts of packet (packetID,offset,length), rejecting any 
> overlaps but passing the valid fragments through. Even a simple border router could keep ensure that no later 
> arriving packet overwrote data from an earlier packet by keeping track of the (ID,offset,length) triplets for a 
> packet and comparing new ones to determine if the overlap. No packet data has to be kept but it ensures that packets 
> passing through are of a standard format so both NIDS and host would assemble them in same manner.

-- 
http://jeff.wwti.com            (pgp key available)
"Common sense is the collection of prejudices acquired by age eighteen."
- Albert Einstein