Transport-layer replay prevention

[zzz]

ref:
​http://i2p-projekt.i2p/en/docs/transport/ssu
​http://i2p-projekt.i2p/en/docs/transport/ntcp
​http://zzz.i2p/topics/1577

Replay prevention is particularly important for what Tor calls "probing resistance", where the GFW follows up a connection attempt with one of its own. Also just to prevent other trouble.

NTCP spec doesn't mention it at all.

SSU spec claims we have a bloom filter of IVs but I can find no such code. The only thing I find is a bloom filter (actually hash set) of message IDs, i.e. only for data packets, and since the message ID is the I2NP message ID, doesn't that duplicate the I2NP bloom filter in the router anyway?

Most important is the first packet (called "Session Request" in both protocols). Nothing in the router's I2NP bloom filter will help us here.

To be effective, need either a DecayingHashSet? or a LHMCache. And need to enforce the timestamps beyond the lifetime of the cache or set. Sadly, there's no timestamp in the SessionRequest? in either protocol.

Some of this can't be fixed until NTCP2 but we could implement basic protections now.

Right?

[zzz]

Testing a NTCP fix using DecayingHashSet? on HXxorHI

[zzz]

NTCP fix for SessionRequest? in 0.9.11-12 76527a672bbf614292c87b4ce89635c0085b04e4

[zzz]

<zzz> to do it completely right you need a timestamp in the same packet as X... which we don't have in either protocol now.

[zzz]

SSU in 0.9.12-5

[zzz]

The implemented changes are not yet documented.

In addition, the Bloom Filter section in SSU has not yet been fixed.

In addition, Message Header section of ​http://i2p-projekt.i2p/en/docs/spec/ssu does not make clear that retransmissions get a new IV too.

[zzz]

<orignal> no reason for NTCP
<orignal> because next message always depends on previous