TunnelEndpoint: implement out-of-order message fragment reassembly

[anonimal]

Look to java i2p's implementation instead of simply dropping the message.

2016-01-18 00:30:44     +zzz    in tunnels, you can fragment as-you-go because there's no retransmission, so you can be smarter
2016-01-18 00:31:43     +zzz    in SSU, you have to fragment up front because individual fragments can be retransmitted
2016-01-18 00:31:46     +zzz    so it gets messier
2016-01-18 00:32:04     +zzz    in SSU, for example, we often transmit the last fragment first, because it's smaller and will fit in a packet that's half full
2016-01-18 00:33:02     +zzz    there's no reason to do that for tunnels
2016-01-18 00:45:04     +zzz    you can always fragment at the GW better so that's optimization. If you don't reassemble correctly at the EP that's a bug. I can't think of any security issues for either.
2016-01-18 00:47:16     +zzz    the quirks at either end could perhaps distinguish between java and c++, but I wouldn't rank that issue very high

[anonimal]

Labeling as critical because the ability to distinguish java i2p from c++ i2p is not inline with our mission statement "The secure, private, untraceable C++ I2P router" and because I consider this distinguishable element as a vulnerability that can be exploited.

[anonimal]

In a perfect world, this would be critical. In reality, given where we are now, and in relation to more critical vectors, its not. Relabeled as medium.

[anonimal]

NOTICE: THIS ISSUE HAS BEEN MOVED TO GitLab. Please continue the discussion there. See #1013 for details.