-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Seth David Schoen wrote: > str4d writes: > >> * No replay detection - packet replay is ignored within the >> lifetime of a session. They suggest that adversaries would be >> deterred by the risk of being detected by >> volunteers/organizations/ASs, but the detection process is going >> to add additional processing time and therefore compromise >> throughput (c/f I2P uses a bloom filter to detect packet replays, >> and this is the primary limiting factor on participating >> throughput). > > If the remote peer has to be actively involved in the onion > routing process, couldn't it detect replays rather than having the > routers do it? Or is the replay problem a problem of wasting > network resources rather than fooling the peer into thinking a > communication was repeated? >
In this design, I would say the major problems are wasting network resources, and forcing router rotation. There is no way to "cancel" a session other than to let it time out. This means that an attacker can replay packets as rapidly as they want in order to overwhelm the participating routers, effectively DoSing the remote peer (as well as anyone else whose sessions are going through those routers). The participating routers can't do anything, because they are stateless and the packets they are processing *are* valid. The remote peer *can* detect the replays, but they can't tell the participating routers about it. All that the remote peer can do is drop all packets from that session, select new participants and switch to a new session - - which increases the probability of selecting the adversary's malicious routers. Perhaps the selection process can be constructed to minimize the danger, but that is outside the scope of HORNET's design. str4d -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVstZjAAoJEBO17ljAn7PgbJMQAI+RQLN473wryhAvQia3XCCA jJrt0qQH+3uarUzuG7JNeIkhThSO7/iCtLLtQpSSCXCXSB0To8xlJ+I3mCyOeGIO J+uMyA8aBnytYWIQGba2EvEeyK5oHCLo0+cHBdcCE0VAK6J42ZHUqd6xpdspFFbg QW4CUk/290aYEhdtraLGEvyOFFGvgSUMVkNmdinm/Gs5vFLZIAGN4SXDagFJktx2 4k+/Gh/a9DZ1/4asVmbrzriF6chxHWI039++YP5V9FyLLaC2Cbgt0bIBZrb2lBK3 EIzwuv42rtlX2PJJQxVbK1MZp35HF4qG+qNcydTYNp6m8b1i1W+ErMljluxJYGKI PWJY7xCr72SDIgsDHh2UMoqAUggEjPo2ZpSSjNHJmyVp4fwIxIgy4jAZGd+K0DFm B9jSWSd9ZzUd4plh16Ye0pZHDe95BPWfZLj2z3e6YYnDV4TvaWxA/SZHuL+/b1HJ 5iQJM1ThvEjVCT4GcN9hsVSl/bJQckOxuzuPL82xA0Mj1cggLYrpwCdSzUga4Kgf bcLTD/Q9xQ5W+PK9IDDP+XTPVQuthLSS77gb19VdKi3PlR2O16rSdCTPL2XDVBJW XmsNzDwX7tO0vK6V3lpCAZ+vwW1zeqleAUl5mSB39rjK5MbpYYqlKCFqalsa/7gf 7glnFEELqupYiDjeAYrt =EZME -----END PGP SIGNATURE----- -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
