Re: merging forwarding & packet filtering?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

Most of what Dennis says I agree with (not surprising, considering that
it's Dennis saying it).  But I have two minor points:

> All things related to NAT are (necessary) evil, and inherently
> require one to keep flow state.

Actually, not quite.  There are some (moderately rare, in today's net)
cases of NAT which don't require keeping state.  (In ipnat terms, rdr
and bimap rules are examples, if I understand them right - I don't use
ipnat all that much.)

> [...] a correctly implemented flow state table inherently requires a
> packet reassembly stage in front of it, so that fragmented packets
> are made whole before the flow lookup, since you can't do a flow
> lookup on a not-first fragment and it is only by getting those
> not-first fragments attached to their first fragment before you look
> up the flow that you end up with everything that needs to going in
> the right direction.

I disagree with this too.  Doing reassembly is certainly an easy way of
doing this, but I don't see it as essential; non-first fragments must
be held until the first fragment arrives, but the packet IDs that drive
reassembly in an end host could equally well drive flow state
selection, rather than reassembly, in a NAT.  (Fragments which include
part but not all of the UDP/TCP header complicate things, it's true,
but it's hardly impossible to deal with the rewriting issues involved,
just annoying, and avoiding the issues reassembly brings might be worth
it in some environments.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B