Rick Jones wrote:
The case of particular concern occurs when the first fragment of a
datagram is lost in the network. The remaining fragments will be
stored in the fragment reassembly buffer. When the sender wraps the
ID field, the first fragment of the new datagram will be mis-
associated with the rest of the old datagram. Assuming the fragments
are delivered in order, the rest of the new datagram will be now be
incomplete (since it is missing the first fragment), so they will be
saved in the fragment reassembly buffer, forming a cycle that repeats
every 65536 datagrams. It is possible to have a number of
simultaneous cycles, bounded by the size of the fragment reassembly
buffer.
Does it really matter if it is the first fragment? I would think that
cycling is possible so long as (any of) the lost fragments are simply
not the last fragment when one assumes the fragments are flowing in-order.
It could matter. If it's a middle fragment, you'll receive some
duplicate earlier ones before the datagram can be completed. If the OS
has a consistency check here (that the data is the same), it could toss
the whole thing when it fails. I'm not aware of any implementation that
does this, but if you're just talking about the first fragment, it's
more clear that it's a problem.
Also, to ass-u-me that fragments flow through the network in-order is
probably not a good thing? Load-balanced link aggregates may send
fragments of one datagram across more than one link in the aggregate,
and I know of at least one NIC, albeit old and likely unused today, that
would send the first fragment last as part of accumulating an offloaded
Checksum (HP-PB FDDI NIC).
However, data is often delivered in order, so it serves as a good
example. :) Assuming in-order delivery is partially for the sake of
clarity. Any order (reverse, first-packet-last) that's always repeated
has the same property. A randomized delivery order is not as bad as the
worst case.
A while back, over in the "netdev" mailing list, the we were discussing
ways to minimize the risk of frankengrams springing to life based on
ass-u-me-ing :) that if one saw N or more datagrams beyond the one(s)
being reassembled, the likelihood of those datagrams successfully
reassembling was epsilon. While the specifics of that may be more
"linux-centric" than an RFC should be, I suspect the discussion might
provide a starting point for a useful, additional section in the RFC
discussing ways transport stacks might minimize the likelihood of
Frankengrams.
It would be a good place to start for a *future* draft on the subject.
We decided it is out of scope for this one.
Thanks,
-John
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
