On Tue, 2006-05-30 at 08:27 -0700, Fred Baker wrote:
> On May 29, 2006, at 6:53 AM, Stig Venaas wrote:
> > Also note that as mentioned above, some implementations send
> > fragments out of order (e.g. Linux has been known to do this). The
> > reason is that you don't know the total size of the datagram until
> > you receive the last fragment. Receiving the last fragment first
> > means that you can allocate the right amount of memory immediately.
>
> On that particular point, since packets can be reordered in flight in
> a best effort network, it seems to me that the sender can neither
> prevent packets from arriving last fragment first. a middle box
> cannot accurately detect that the sender did or did not do this, and
> the receiver cannot depend on packets being sent last first. So if it
> happens it happens, but thinking very hard about it sounds like a
> fool's errand. Better to simply hang on to the mblks-or-equivalent
> until the segments have all arrived.
IMHO NAT's(*) and Firewalls are to treat the IP they are passing as they
are end-hosts. They are in the middle and want to do full packet
analysis/translation/filtering. There have been a number of problems
with firewall vendors making a wrong implementation where it was trivial
to send fragmented packets in such a way that it either caused the
implementation to pass those packets on, while they should have
firewalled those packets.
Thus the sole issue, not issues as in the section title, with firewalls
is that the firewall implementation is broken as it does not handle
fragmented packet assembly properly. If the firewall would properly
handle reassembly then there would be no issue, whatever nice or
not-so-nice people would send to it. If they are passing through
fragments, how sure are they that the receiver actually wanted to
receive this in the first place, or is it just guess work it is doing?
From my point of view this is thus a real implementation issue, which
might be good to note as informational to the implementators, but not
something that should make all implementations worldwide to change their
behaviour, as they are doing it correctly. Policy Boxes are the same for
me as firewalls, I wonder why they are listed separetely, or do
"Firewalls" not apply any "Policy" ? :)
NAT-PT is (afaik on the list for) deprecation, thus we should not care
about this either. For the ones that want to implement it: act like an
endhost and handle the fragementation in that manner.
As for the proposed solutions, it lists the misses option E:
" Reassemble all the fragments, and transmit the packet on when
the packet is okay for the policy or translation that needs
to be applied to it".
as that is what an end host would do also: it would re-assemble the
packet and then pass it on to it's next hop, usually the user-space
application.
Section 6 IMHO is completely bogus as it would mean all the existing
implementation would have to be changed. As there are people still
clinging to ip6.int for instance and that is only DNS, you really think
that all the implementations around the world would start doing this?
Next to that, in case you would have a cellphone or other lowbandwidth
device, eg a network of 100000 sensors on your carpet, you don't want to
send out 1280 bytes instead of only the 40 that you want because of
various concerns like powerconsumption etc. Next to that, what does one
do with the trailing data that should not be there in the first place.
Also, if we would 'align' packets on 1280, we might want to start doing
this for multiples of 1500 etc too at a certain point, the end would
become endless at a certain point.
Adding these changes to IPv6 would IMHO cause more problems than it is
worth, afaik no currently 'nice' implementation causes issues with
fragments in this way, thus it is only to 'protect' against the
not-so-nice implementations, who will try anything they like anyway.
Maybe we could consult RFC3514? :)
Otherwise said: fix the implementations of the middle boxes and warn
them for this issue in the arch rfc's.
(Then again if they did't get that fragments and other weirdly
constructed packets will cause issues with their firewall...)
Greets,
Jeroen
* = Who came up with the silly idea of making an IPv6 NAT box!?
If one expects/want NAT then please stick with IPv4, no need
to start abusing IPv6 for that.
Attachment:
signature.asc
Description: This is a digitally signed message part