Date: Tue, 10 Feb 1998 11:32:30 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: nash@Mcs.Net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ipfw logs ports for fragments Message-ID: <199802101932.LAA02216@bubba.whistle.com> In-Reply-To: <Pine.BSF.3.95.980210093828.6400C-100000@Jupiter.Mcs.Net> from Alex Nash at "Feb 10, 98 10:58:39 am"
next in thread | previous in thread | raw e-mail | index | archive | help
[ private email re short term fix to ipfw code, copying to hackers... ]
Alex Nash writes:
> > Archie Cobbs writes:
> > > - If it's a pass/accept rule -> packet should match (ie, PASS)
> > > - If it's a deny/reject rule -> packet should NOT match (ie, PASS)
> > > - If it's some other kind of rule (skipto, divert), .. leave it
> > > like it already is -> packet should match, though this is still
> > > broken.
>
> I can't see passing packet fragments which are not supposed to pass
> as being the right thing to do unless someone explicitly asks for it. If
> we were to do that, why not pass all fragments?
Something just bugs me about this whole thing. The bottom line is
that you simply can't tell, given the available information, whether
a rule that specifies port ranges and/or TCP flags should match a
non-zero offset fragment. And even if you had the available information
(ie, the first fragment), it's still unclear what the semantics of ipfw
are supposed to be.
Does the sysadmin want us to correlate the fragment with the first
fragment of that packet, then apply the rule iff it matches that
zero-offset fragment?
Does the fact that the rule does not specify IP_FW_F_FRAG mean that
the sysadmin did not intend this rule to apply to non-zero offset
fragments?
In other words, if we fill in all the details of the ipfw man page,
then we'll have our answer.
As a side note: in any case, we need to modify check_ipfw_struct()
to disallow any rules which (a) have port ranges or TCP flags, and
(b) have the IP_FW_F_FRAG flag set. Such rules simply don't make sense.
But what is the semantics of NOT specifying the IP_FW_F_FRAG flag?
Does this mean the rule ONLY applies to zero-offset fragments?
PROBABLY NOT -- this would be different, unexpected behavoir. Plus
everybody's firewalls would suddenly start leaking non-zero offset
fragments, which would be harmless but silly. OK, let this be decided.
HOWEVER, this conclusion poses a problem in the port range/TCP flags
case in the context of the current code -- you simply don't have enough
information (ie., the first fragment) available to compute the "right"
answer. SO -- we simply have to make an exception in this case and
document it.
Now the question is.. which exception to make?
#1 Don't even TRY to match rules containing port ranges and/or flags
to non-zero offset fragments.
#2 Match port range/flag rules to non-zero offset fragments by testing
the rule AS IF it did not contain the port range and/or flag
restrictions.
#3 Do something more complicated (like I proposed).
Note that #2 is our current behavior. Now I'm thinking we should
stay with that. #1 is OK too. In any case, we have to choose one of
the above, and most importantly we need to DOCUMENT it... e.g:
#1
The "frag" option restricts the rule to only matching non-zero
offset IP fragment packets. Lack of this option means the rule
may match any IP packet. However, there is one exception to this:
if a rule specifies a port range or TCP flags, then the rule
will never match non-zero offset fragments, since such fragments
do not contain this information. This means that these rules can
possibly fail to match fragments of packets for which they were
intended.
#2
The "frag" option restricts the rule to only matching non-zero
offset IP fragment packets. Lack of this option means the rule
may match any IP packet. However, there is one exception to this:
if a rule specifies a port range or TCP flags, then these options
are temporarily removed from the rule when it is applied to non-zero
offset fragments, since such fragments do not contain this information.
This means that these rules can possibly match fragments of packets
for which they were not intended.
Etc... Take your pick.
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802101932.LAA02216>