Rick Jones wrote:
But it is still bad, and I worry (fear, uncertainty and doubt, oh my)
that someone reading the draft will say "oh, good, my stack does things
in a different order so it must not be so bad"
Maybe just some "while we use in-order as an example the problem is
still present and bad with other packet orderings" text.
Will try to make this a little more clear. Thanks for the input.
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.
Maybe it is drifting a bit, but isn't it rather like announcing a
vulnerabilty without announcing how to mitigate it?
I'd say it's more like when a bridge is out, first putting up a warning
sign, then worrying about how to fix it. ;)
Seriously, we considered writing a section like this. But on careful
thought, it was not obvious how to mitigate the problem robustly. The
Linux solution works pretty well under specific conditions, but writing
a BCP on how to safely use fragmentation for high bandwidth apps could
get thorny. The safest thing to do is just not use fragmentation for
these apps, or if you absolutely must, at least add protection (like IPsec).
Thanks,
-John
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
