Opened 8 years ago

Closed 3 years ago

#1212 closed defect (fixed)

Transport-layer replay prevention

Reported by: zzz Owned by: zzz
Priority: minor Milestone: 0.9.37
Component: router/transport Version: 0.9.11
Keywords: security ntcp ssu docs Cc: orignal
Parent Tickets: #2199 Sensitive: no



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.



Change History (9)

comment:1 Changed 8 years ago by zzz

Status: newaccepted

Testing a NTCP fix using DecayingHashSet? on HXxorHI

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by zzz

SSU in 0.9.12-5

comment:5 Changed 7 years ago by zzz

Cc: orignal added

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.

comment:6 Changed 7 years ago by str4d

Keywords: security ntcp ssu docs added
Milestone: 0.9.15

comment:7 Changed 7 years ago by zzz

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

comment:8 Changed 4 years ago by zzz

Parent Tickets: 2199

comment:9 Changed 3 years ago by zzz

Milestone: 0.9.37
Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.