I agree - we are all on the same page with respect to randomization, I believe. Just a couple of things:
1. In the face of multiple sign-ons, the clients have different full JIDs (or at least, they should). If there is a JID mismatch I treat it as a RTT message from a different login and as a loss of sync until the next message refresh. It seems that Section 6.6.4.2 encourages this - so maybe it would make sense to make this more explicit as part of the processing rules? 2. I like having a 2**30 space for randomization, rather than 2**20 because it makes the sequence a bit more unpredictable. I don't know if it it ever will make a difference, but it's one of those things that reduce potential attack vectors, and this, in my view is worth the tradeoff of having a few extra bytes for the decimal representation of the sequence number with the larger space. Christian On Fri, Apr 12, 2013 at 9:52 AM, Mark Rejhon <[email protected]> wrote: > On Fri, Apr 12, 2013 at 9:47 AM, Mark Rejhon <[email protected]> wrote: > > On Fri, Apr 12, 2013 at 2:48 AM, Gunnar Hellstrom > > <[email protected]> wrote: > >> - on the sender side I limit the maximum random sequence restart number > to > >> 2**30. > > Chris/Gunnar apologies, I may have mis-read: > I may have answered as if: > - on the sender side set sequence restart number to 2**30 (same number > every time) > Rather than: > - on the sender side I limit the range of maximum random sequence > restart number between 0 and 2**30. > > Since you both probably talked about the latter, then that was, of > course, the intent of the standard to recommend randomization of seq. > > Mark Rejhon > -- Christian Vogler, PhD Director, Technology Access Program Department of Communication Studies SLCC 1116 Gallaudet University http://tap.gallaudet.edu/ VP: 202-250-2795
