On Saturday 27 October 2007 05:52, Srivatsan Ravi wrote: > Nonce Ni allows the initiator to reuse the same exponential across the same > sessions(with the same or different responders) within the PFS interval > while ensuring that the resulting session key will be different. Thus we can > use it to differentiate between different parallel sessions( Can the > initiator handle the demultiplexing? )
The problem is that we sometimes have several IP addresses for a node, and we will send handshakes to all of them simultaneously. If they all succeed, we will have to choose which to keep. We can't make the choice at receiving stage 2. In the short term, we will just keep the current code: the last success clobbers the first success. In the long term, we will probably support multiple simultaneous connections at least for a short time, and have some way to decide which one(s) to keep. > > On 10/27/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > > > > Various odd errors recently (PacketSequenceException for example) seem to > > have > > been caused by running several JFK negotiations simultaneously and all of > > them succeeding. STS was stateful and therefore could only have one in > > flight, but JFK can have more than one. > > > > > So one completes, then another > > completes; this exposed a bug which I fixed, but it is problematic as the > > second connection will clobber the first. > > What does this mean? > > Options: > > - 1) Introduce some state, resend the same message 2 after receiving the > > same > > message 1. Bad: memory DoS. > > - 2) Ignore the problem. It works, don't fix it. Probably what we'll go > > with. > > - 3) Stagger the sending of the phase 1 handshakes. The problem is that we > > may > > have to keep firewall tunnels open, so we have to send to each address > > every > > <30 secs. But there should be space within this to send to a few > > addresses... > > - 4) Support multiple temporary connections. Drop according to a defined > > order > > in the noderef. > > - 5) Support multiple permanent connections. Separate AIMD for each > > connection, so messages can be distributed according to whichever > > connection > > has the lowest RTT and has available bandwidth. > > > > Any comments? > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071027/b17993e6/attachment.pgp>
